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.
- Make an empty message type optional mean "no message"
- Set message type for all actions that send a message through the normal mechanism
- Remove now redundant bool specifying whether a message should be sent
Since _ls is now deprecated this is removed in favour of L1, I've also taken the oportunity to replace QStringLiteral and QLatin1String with their shortened form while we're at it.
There are also a few instances where the string literal type has been switch, the general rule being to use the one that matches the function type or value being compared to avoid conversions.
ThreadModel was not updated to use pendingEventAdded the same way MessageEventModel was so new messages in an exisiting thread were not being initialised properly. This fixes it to use the updated pendingEventAdded on new enough versions of libQuotient.
Use the new thread functionality in libQuotient to show the thread on the latest message rather than the root.
Note: to test you need to bump your libquotient minor version to 10 or higher.
Also Note: this reveals some other bugs in how new threads are shown or refreshed when new messages are added, this will be fixed in a later patch as some re-architecting is required
Some clients - such as Element - can send colored text through <span>,
which fails to display in Qt's rich text parser. So we need to transform
that into CSS styles which is supported by Qt.
Notably this allows you to exchange rainbow shrugs through Matrix, which
is really important. And this means colored backgrounds for text is
supported too, I guess.
https://invent.kde.org/network/neochat/-/merge_requests/2005 changed the custom emoji height (whose default is 32 on every Matrix client) to match font height (on my machine it becomes 17, my font is 12pt).
It makes emojis unreadable on non-HiDPI resolutions (1366x768, 1920x1080), and even in the MR itself you can see how much detail is lost. This is compounded by some other rendering bug where the emoji image becomes very jagged when downscaled.
That MR however was correct in that:
* we want custom emojis to have a different size than unicode emojis
* we want custom emojis to be centered according to the text (to make better use of line spacing/paddings)
* we don't want the line height to be changed (too much) by custom emojis
* we (probably) want custom emojis to be _displayed_ proportionally to the text
I'm investigating ways to solve this issue. It seems other Matrix clients (and even chat applications like Telegram or Discord) all globally suffer from this issue and have dealt with it in different ways, sometimes masquerading it and sometimes working around it.
For now though, we shouldn't break emoji legibility for our users. Affecting line height by a few pt is a minor issue compared to being almost unable to tell what inline emoji you or your interlocutor is using. Even just the "center emoji with text" thing already makes the line height issue 1/3 less of a problem. Once we improve the emoji rendering so it's more readable, _then_ it would make sense to decrease the emoji height to something like font.height * 1.6 or so.
This does not affect unicode emojis, as far as I can tell those are handled elsewhere. This only affects inline custom emojis.
Illegible on 1366x768 with 100% scaling and font size 11:
{width=1025 height=576}
Legible:
ECM recently started adding -fhardened, which makes us crash here since we're doing things that aren't valid, but happened to work out fine previously.
This is basically prep work for customisable sort orders. The room sort parameters are detached from the room sort model as multiple components will need to access the values. The sorting is then generified.
Some defunct sorting parameters are also removed.
When not modal, dragging the edge of the room drawer to change its width felt very broken.
This seems to be a collision between Qt's dragging logic and our dragging logic,
so we disable theirs if the drawer is not modal
