Replace HoverActions with an inline action component that appears on hover. There are only actions for reply and react if there is space the overflow button opens the normal message menu.
NOTE: the most recent update changes things slightly, from the images below the buttons are now top aligned because of potentially hige messages. The actions are also now disabled for compact mode as they never really made sense there anyway. The menu now has all options so no one is missing out.
For normal messages
{width=419 height=138}
When space is limited
{width=411 height=130}
User messages
{width=296 height=114}
BUG: 503784
I was hitting one more annoying crash with a backtrace inside QCache,
because we didn't set the ownership propetly for one last model. Now I
don't hit it anymore.
Currently, this is something that's missing even in clients like Element
(!?!) I will sometimes miss when invites are sent - like when I'm
sleeping - and then when I start back up NeoChat I have no idea when
they tried to invite me. This can get worse on bigger timescales, like
when you go on vacation for a few days.
Similar to spoilers, some Markdown flavors like GitHub's or Discord's
allow you to strike through text with ~~. Normally, the only way to do
this on most Matrix clients (including Element) is surrounding text with
<del> tags. As expected, no one knows how to do this.
So now NeoChat supports the ~~ syntax. We can reuse the existing spoiler
parser for this after making it generic. I have added new test cases for
this syntax. This does not affect the quick format bar yet.
When you reveal a spoiler, it removes the background from the spoiler
block - effectively making it seem like regular text. There's also a
minor issue that we use the color scheme's textColor as the "spoiler
block" color, and it will usually end up white. Most chat programs have
typically used a dark background for spoiler blocks, even on dark
themes.
I killed two UX issues with one stone, first by making the spoiler block
color fixed (but mixed with the textColor, to ensure it's readable
regardless of Breeze Light/Dark.) And second by only changing the text's
visibility, not the background.
Currently the only two ways to spoiler text in your message is either:
* Using the /spoiler command
* Manually typing the data-mx-spoiler span HTML blocks
Neither one is discoverable, or friendly to users really. Instead, we
should extend our existing Markdown-based formatting syntax with one
that can handle spoiler tags. I chose the || syntax to match Discord,
since Element doesn't seem to adopt one.
Unfortunately, CMark does not support custom extensions (see
https://github.com/commonmark/cmark/pull/123) so we have to implement
our own parsing function. New tests are also added for this too.
This doesn't need to be attached to an instance of MessageDelegateBase,
and avoid various problems when called from a MessageObjectIncubator
callback. (Because it needs access to the "this" pointer.)
Fixes a regularly occurring crash when switching rooms.
This should be set *before* we clean up the incubator, because it could
end up accessing invalid data when the incubator is freed. This fixes a
regularly occuring crash when switching rooms.
This is only called after we already get an event with lastEvent() so
doing it again is useless. Instead, we should refactor it to behave like
similar functions (e.g. isEventHighlighted.)
Most of the data in the objects will be empty, but at least a valid matrix id is provided.
This fixes missing data in some places in the UI (e.g., in HiddenDelegate)
Rework MessageDelegate to be mostly a cpp class. This allows us to only load the components that are actually needed saving memory.
In testing using memtest it saved ~30% versus the current implementation.
Force the room list items to update their height when the compactRoomList setting is changed.
The solution is a bit janky but for whatever reason the height wasn't updating properly which seems to be a qml bug, it sometime happened slow, sometime you would have to turn NeoChat off then on again.
BUG: 494146
It seems like the case is possible as we already are treating the case
in isUserBanned. Doesn't seem ideal as it shows "" where the username
should be but it's better than a crash.
I'm 99% sure of the recent crashes we've been seeing are double-frees,
the QCache one me and Duha encountered must be one. The QCache is in
charge of the one in ContentProvider, so it will sometimes try to delete
or access something already destroyed by the QML engine.
While I'm at it, I also made sure to check every other Q_INVOKABLE to
ensure we don't hit this elsewhere.
CCBUG: 502747
In chatBarSizeHelper, if user is in compact mode and resizes the window,
maxWidth would be -1 and that caused something to go wrong with the
padding calculations.
Instead, just set it to root.width with some padding, so it always is
the width of the ChatBar.
