- Refactor and cleanup code
- Don't paginate through notifications - it spams the server with requests and realistically only contains anything relevant on startup after a long time, in which case you're going to lose some notification anyway
- Only show newest notification for the respective room, closing the old notification if one exists
- Only show text of this notification
BUG: 475228
Some of our search pages (such as the room and user search) has a list
header item. Due to how this works, it's not actually a part of the
list view keyboard navigation and a whole separate item. So in the tab
order, it comes *after* the list view which makes no sense. And it's
part of the list view, so users must expect it to be selectable with the
up and down arrows like other items.
This simple change makes it so it behaves as expected. The first actual
list item is selected by default, but it's possible to navigate to the
list header item via the up arrow key and then return to the list view
using the down arrow. The list header item is also removed from the tab
order and the whole page is much nicer to use now.
One of them didn't even have a tooltip, which is a simple oversight
since it already has accessible text. The tooltips now use the attached
property instead of creating a new QQC2.ToolTip too.
Some of the items were able to activated via the keyboard, but many were
not like the notifications and "create a space" buttons. This is because
the signals were hooked up to onClicked but the accessible and keyboard
nav were hooked up to onSelected. All of the buttons trigger their
actions with onSelected now.
This was previously not keyboard navigable at all, making it
impossible to switch servers in this dialog solely with a keyboard. This
patch makes it possible to do some basic selection but not deletion yet,
but it's a good start.
Previously it was possible to keep clicking and highlighting each member
which doesn't make any sense. We could make this exclusive by having it
highlight only when index == currentIndex, but honestly it doesn't need
to be highlighted at all. Clicking on a room member opens their user
card, there's no persistent state the user needs to keep track of here.
There are 2 main reason for doing this:
1. Because I can, I wanted to see if I could do it
2. It gets rid of the janky qml re parenting stuff so should be faster.
Add a model for managing permissions (power levels) in rooms. This gets rid of a whole bunch of boiler plate in NeoChat and as a bonus makes it easy to add a feature to allow setting the permission level for any event.
Improve the behaviour of jump to last unread message. The view will now jump as high as possible if the last unread message isn't loaded. This at least triggers more items to load which will eventually get the user to the last unread message.
Sometimes this part of the code causes segfault for me.
I don't know what the root cause is though, it's *very* random. I guess the tagToken should always be long enough, but sometimes it's just one character.
