New messages are now going through the following steps:
1. MessageModel::addMessageRequested() needs to be emitted
2. MessageDb::addMessage(): Deduplication is run (follows in one of the
next commits)
3. MessageDb::messageAdded() is emitted
4. MessageModel::addMessage()
Moves the message notification sending from the MessageHandler to the
MessageModel. Sending notifications is generally a GUI task (not XMPP
backend) and is also problematic there because it should be done after
message deduplication.
Before this everything from QML that wanted to communicate with the XMPP
thread and the XMPP managers needed to use signals in Kaidan.h. The new
concept makes it possible to access the XMPP Managers directly although
you still need to use signals in order to communicate with the different
threads.
The message ID in the database describes the ID of the latest message
correction now (instead of the ID of original message). There's a new
column in the Messages table now for storing the 'replaceId', the ID of
the original message.
Little GUI change: Unavailable options in the message context menu are
invisible instead of being disabled.
This changes the way MessageModel concludes whether the message is
suitable for correction. A message can be corrected, if:
* it is `sentByMe()`
* is amog the latest 20 messages sent by us
* is not older than 2 days
Also instead of searching the message with the correct ID, the function
now uses the index from QML instead.
* Add actions for opening chat and marking messages as read
* Do not notify for new messages when sender is muted or chat with sender is already opened
Co-authored-by: Jonah Brüchert <jbb.prv@gmx.de>
Co-authored-by: caca hueto <cacahueto@olomono.de>
Co-authored-by: Linus Jahn <lnj@kaidan.im>
Writing messages in the database while offline, sending pending messages
from the database on connect
This also adds new icons for the different delivery states.
This rewrites parts of the main database class. All classes working on
the database have been moved to the new database thread, so inserting
records into the database isn't blocking the user interface anymore.
What also improved the performance *massively* is the use of SQLite
transactions, when inserting multiple records. So inserting is so fast
now that it actually wouldn't necessarily require another thread, but
with this we're safe in the future.
The message model and the roster model have been splitted up into a
database manager and the list model that is used to present cached data
to the user. The XMPP managers are connected to both the model and the
db classes, so both are updated in parallel.
There are also two new classes for the RosterItem and the Message,
because we need to cache those in the models in a vector. The Message
class inherits from QXmppMessage, so we can now use the same class for
sending messages and inserting messages into the database.
Closes#273.
There are upcoming changes of the expected behaviour when correcting a
message multiple times. The old way was to correct the last correction,
the new way is to always correct the original id.
See https://github.com/xsf/xeps/pull/764
There were three edge cases:
1) The wrong message was replaced:
- You send a message
- You open the edit menu
- Contact or another device of you sends a message
(lastMessageId is updated)
- You finish your edit and a message is sent to replace your contacts
message, which is obviously not what we want. Database and XMPP
both get the wrong message id to replace.
2) Can't edit last message:
- You send a message
- Contact sends a message
(lastMessageId is updated)
- You can't edit your last message, although that is expected to work.
The solution was to only update the lastMessageId for own messages.
Also the QML code has been slightly beautified by the use of a signal.
Spoiler messages are used to hide messages containing NSFW content / very long
messages / secret content by default. Kaidan can now send & receive those messages.
A context action on the chat page has been added for this purpose.
Details about the XEP:
https://xmpp.org/extensions/xep-0382.html
All media hashes are now saved in the messages table. They are saved just in the
XML format of 'XEP-0300: Use of Cryptographic Hash Functions in XMPP'.
This also adds a mediaThumb column to the messages table.
With this local file paths, content types, sizes of file uploads are saved in
the database.
The database has some new columns for the media information and the version has
been increased to 6.
This also contains some clean ups and minor improvements of the code.
This introduces different message types (text, image, video, audio, document,
file). They should be used to determine the correct message element in the UI.
Also, there is a new mediaUrl in the Messages table which will be used to
save the HTTP urls to download the media shares.
The database version is increased to 5.
This also does some clean up and restructuring of the deployment of the
`chatPartner` property to the ClientThread (MessageHandler) and MessageModel.
Before, a thread-safe function of the ClientThread was used, so the mutex of it
blocked the GUI, when the client thread was busy in this moment.
