Currently it uses applicationWindow().overlay which works but is
not ideal for multiple reasons:
- This as a tendency to breaks unexpectedly
- It can't be optimized by the qml compiler
So we are trying to move away from these construct everywhere.
Store NeochatRoomMember objects in the room so we don't duplicate them unnecessarily. This also adds a visible property for a room which is set true when shown by MessageEventModel and false when not, triggering the deletion of member objects. This mechanism will be used for other object types in the future.
Create a simple app that puts a number of events into a simple timeline which can be used to verify future memory optimisations
When Neochat is built with tests on you should find the app at ~/kde/usr/bin/timeline-memtest assuming ~/kde is your kdesrc-build directory
Set KilledJobError to indicate it was canceled by the user
to avoid a bogus "finished" notification.
Sadly, fileTransferCanceled has been removed from libQuotient
so this lambda botch checking transfer status needs to be done.
There's no such thing as Emote or Message anymore, it's all "Text".
Matches IsEditableRole of MessageEventModel.
While at it, also clear threadId, which is what the Edit quick
button also does.
Since the new thread API was released in 0.9.2 update the if defs to include it. This will solve the double chat bar in thread for anyone on 0.9.2 or above
My go to place for doing anything with rooms, is the search button.
However, I cannot join/find new rooms from there. Therefore this adds
an "Expore rooms" button as helpful action when there are no matching
rooms.
Key-specific handlers, such as Key.onDeletePressed implicitly accept
the event. This means that the entire logic for the delete key must
be reimplemented, and e.g. Ctrl+Delete to delete the previous *word*
was missed.
Since all it has to do is handle the typing notification and format bar,
just use the already existing Keys.onPressed handler (which does *not*
accept the event) and add a case for Delete alongside Backspace.
It doesn't make sense for a thread to be on the right or tinted when the local user started it as they contain messages from multiple users. So always make them align left and never tint them.
