Using a callback to display a sent message inside the ChatControl means
that all messages we send have to be issued from the GUI layer
(send_message()) if we want them to display in the ChatControl.
This replaces the callback and catches the stanza-message-outgoing event
after it was processed by the core.
This is easier to read/understand than dealing with callbacks and lets
the core issue messages without having to care if a ChatControl is open or not
- Complete rewrite of the old Groupchat dialog
- Has now a "minimal" mode, which is used if we have all infos for joining except the nickname and if we want to bookmark
- Handle xmpp uris received via command line
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.
- Calculating so many hashes for each Message is quite expensive
- It hides our own implementation bugs, like when we retrieve history
from a MUC with wrong timestamps, or on rejoin. We never know about it
because the Messages are dropped.
- It should not be necessary anymore. The original problem was a bug
in nbxmpp which triggered mass resending of old messages.
Right now oob data is merged into the message text and stored into the DB.
If we load this message from the DB we cannot know anymore if and which
parts of the text was oob data.
Use the additional_data api to store oob data into the DB instead of
altering the original message text.
This lets us decide later on if and which data we want to display, even
on history replays. Also plugins can use the data.
Philipp Hörist
André Apitzsch
Yann Leboulanger
Yann Leboulanger
Emmanuel Gil Peyrot