This was somehow lost once we implemented random resource strings
Although its good that initally a random resource is chosen, it
still should persist across sessions.
This helps to kill zombie client connections on the server because
most servers kill the old session once a new with the same resource
connects
Also dont notify the user about resource conflicts if no custom
resource is set. We should not expect users to know about resources
and what they are used for as long as possible.
- Move ActionBar into HeaderMenu
- Make Design of ChatControl look cleaner
- Hide the Roster in Groupchats per default
- Add Button to hide/show Roster in Groupchats
- Move Groupchat topic into popover
- Display Avatars on the right side of the ChatControl and status on the
left
- Add a default Avatar for contacts that have none
We use PubSub only on our account jid, this use case is what PEP
was made for. If PEP is discovered we know that certain PubSub
features are supported, see: https://xmpp.org/extensions/xep-0163.html#defaults
The current check for <feature var='http://jabber.org/protocol/pubsub'/>
is pretty useless, as it just tells us that there is a PubSub implementation
but not much about the features. Only `publish` and `subscribe` are MUST
in XEP-0060 which is not enough for our needs.
If there is ever need to discover a generic PubSub implementation
that is not PEP we should check for all the PubSub features we need
instead of only for <feature var='http://jabber.org/protocol/pubsub'/>
- Add support for Pubsub Avatars
- Dont poll for vCard Updates, only use XEP-0153
- Dont cache vCards
- Store the avatar SHA of roster contacts in the DB
- Store the current SHA of each contact in the Contacts Object
- Move some code into the ConnectionVcard Class
_registered_name is None on a smacks resume.
Gajim creates on every connection attempt a new nbxmpp.NonBlockingClient
instance. This is why _registered_name is None when we go through a
smacks resume, because there is no bind event, and the new NonBlockingClient
instance has no knowledge of the previous successful bind.
We get our full JID on the bind event.
After that it is saved in the `registered_name` attr on the Connection
Object.
In case the bind never occured we get the bare JID from config.
- Refactor get_last_date_that_has_logs()
- use NATURAL JOIN in SQL query instead of multiple SELECT via
_build_contact_where
- make code more concise
- update method documentation
_continue_connection_request_privacy() should only trigger
once after we received the discoinfo on the hostname.
We do a discoinfo on all items that the server offers,
_continue_connection_request_privacy() was triggered on every received
discoinfo again, hence requesting metacontacts and delimiters again.
also _continue_connection_request_privacy() was called on every
discoinfo error, instead of only on a hostname discoinfo error.
This bug is only triggered if the server doesnt support privacy rules.
The purpose of
`if version and not gajim.contacts.get_contacts_jid_list()`
seemed to be that when cache.db is empty (maybe it was deleted)
`gajim.contacts.get_contacts_jid_list()` should come back empty.
So on an empty roster cache, version was set to None, so that we
request in any case a new roster.
The Problem is that `gajim.contacts.get_contacts_jid_list()` is not
a good indication for an empty cache.db. On start we trigger a
`RosterReceivedEvent` which does a DB query to get the roster. Even
if that DB query comes up empty, the Event is still pushed.
In the event handler `_nec_roster_received` in roster_window.py we
add then previously open controls and our self (if the option is set)
to the roster, making `gajim.contacts.get_contacts_jid_list()` return
these contacts and hence the condition in `request_roster()` always
False.
So the version is set in the roster request, and if there is no new
version on the server, we request no new roster even though we only
have ourself and previously open controls in our roster.
As a solution for this we delete the roster version from the config
in `RosterReceivedEvent` if the DB query comes back empty, which
triggers a new roster request.
muc_restore_timeout set to -1 means we want no particular time set, up
to which we request messages. But we should not deliberate request
messages we already have. Hence even if muc_restore_timeout is set
to -1, we should only request up to the last message we received.
Example:
If we receive a message the last message date is now.
If we restart Gajim and join the MUC again, `time.time() - timeout`
will be most likly smaller then when we received the last message
If the timeout is an hour, this would mean that many messages are requested
from the archive which we already received.
So we always want the most current timestamp (MAX).
Yann Leboulanger
Philipp Hörist
Yann Leboulanger
André Apitzsch