This matches the behavior in other room lists. I also tried to normalize
the constructor with SortFilterRoomTreeModel.
(cherry picked from commit 847db41fb3)
For some reason I don't understand, the ItemDelegate used for these
sections are ginormous. There is quite a bit of padding which confuses
users as its unexpectedly used for the tap area.
I changed it so we only listen for taps inside of the contentItem
itself, which is a more suitable area.
(cherry picked from commit 115d4e7466)
I did this for images a while back, but not for these. Otherwise you
can't press escape or perform other key navigation functions easily.
BUG: 515462
FIXED-IN: 25.12.2
(cherry picked from commit 793f81e733)
The comparison operator was reversed, and this was seen with mark as
read being broken and buttons showing up at the wrong times.
(cherry picked from commit 9ace01f74a)
This is just more ergonomic (in my opinion) as you usually want to
select some text from a code block, instead of maximizing it. There's
already an easy-to-access button for maximizing if you want to.
BUG: 499048
FIXED-IN: 25.12.2
(cherry picked from commit 332a822996)
We still had the default opaque background for RoomPage. I added a
comment too so it isn't removed accidentally in the future.
BUG: 513363
FIXED-IN: 25.12.2
(cherry picked from commit f145bbe8db)
This is some bug in Flow (that is really hard to debug, I can't get it
to exit at all) but we can work around it for a minor visual impact. It
seems to me allow the reaction list to become slightly larger, but
that's about it.
BUG: 504344
FIXED-IN: 25.12.2
(cherry picked from commit 93e932c09c)
This is similar to the TimelineView hacks, but this time its the header
item that's changing height as our room topics and such wrap.
(cherry picked from commit 6eb2b2e739)
This is due to some kind of bug in ListView that never resettles
properly for bottom-to-top views. This can arise when the pinned message
is loaded (because that squishes the view) or the window is resized
(because that also resizes the view.)
We can work around it by assuming the following:
1. The RoomPage knows the window is resizing because it gets its height
changed before TimelineView.
2. The first height change can be a marker to position the view at the
beginning.
This fixes the issue for me, I did the following in order to test this:
* Switch between many rooms, especially ones with a pinned message. Now
all of them start at the bottom as they should.
* Resize the window, ensure that if you scrolled it stays around that
position - otherwise it sticks at the bottom.
(cherry picked from commit 39de4d10e4)
I found that 50% of the time, NeoChat won't restore the last space but
instead get stuck at Home. Even worse, it will overwrite Home's last
opened room with the one from the space - resulting in really buggy
behavior.
The reason why this happens is partly due to the space hierarchy cache
(I think) but that's not the real problem in my opinion. During
setCurrentSpace, we needlessly update the last space & room config
despite us being the ones already reading it.
In addition to that I also refactored this code a bit to be more
consolidated and readable.
(cherry picked from commit 4c37dcf518)
This fixes the annoying "I just scrolled down to the bottom, how come
NeoChat doesn't think I did?"
From what I can tell this is also ListView bug (or something caused by
our style/Kirigami) that creates cases like contentY being -643.2 (for a
ListView of height 643) thus that's not "at Y's end". For our case
though, we don't care and can safely round it.
(cherry picked from commit 3c77711417)
Changed a check to use isDirectChat (which is a clearer indication of
what we want.) I also made sure not to show the account name if you only
have one, since that's just useless noise.
(cherry picked from commit fc6f345036)
`decryptMessage` returns null if it fails to decode the passed message. This value
then got fed into `EventHandler::richBody` which logged a warning and cleared `m_pinnedMessage`.
If we instead retain the value as an `EncryptedEvent`, the UI will pin the encrypted event
placeholder instead of hiding the existence of pins.
(cherry picked from commit 71c84be4b4)
`room()->decryptMessage()` returns null if the message fails to decode. Since elements of `m_pinnedEvents`
get directly dereferenced in getEventForIndex, storing null values leads to a segfault.
In this case we should retain the EncryptedEvent to let the UI report the error.
(cherry picked from commit b684fb451d)
