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
I need this from time to time. For example, debugging an API call or
scripting something with the admin API. This is buried under developer
settings so hopefully no one starts sharing this willy-nilly.
Element Web does something similar, except theirs is hidden under Help &
About.
The combobox has several drawbacks:
- It's not sorted in any meaningful way
- It doesn't have a search
- It doesn't show the icon and last message
This makes it hard to find the intended room in that dialog. The ChooseRoomDialog provides these things for us
Check m_accountsLoading and m_connectionsLoading separately for removal as when loadAccessTokenFromKeyChain() fails m_connectionsLoading won't have an entry for it
