When we are invisible and restart the client, set ourself to invisible,
not offline, and correctly keep the status message that should be set
whenever we get back to a visible online.
If our presence is invisible from the first sync, we'll never receive a
presence event telling us so.
The server just knows from the beginning, so show our local presence as
echo instead of echo_invisible (which causes the half-opacity presence orb)
If another client becomes invisible/offline or we stop syncing for some
time (due to e.g. connection issue or debugger freeze), the server will
tell us our presence is offline. Following this update would lead to our
our current connection being terminated, so ignore it.
Side-effect: if we become invisible and another client with this behavior
is using the account at the same time, this will result in us becoming
online/unavailable again a few seconds later, since we follow
updates for these status to avoid conflicts
- Allow using invisible mode on servers not supporting presence, to
make use of the prevention of sending typing notifications and read
marker updates
- For servers not supporting presence, display the account's presence
orb in the left pane with half opacity
- Indicate in the presence orb tooltip when the presence we set hasn't
yet been noticed by the server/the server doesn't support presence
- When reconnecting after being offline, if the server doesn't indicate
we have a status message [set from another client], restore any
previous message we had set in the current client
- Show our status message striked out when we're invisible or offline to
indicate that it isn't being broadcasted
- Some code style cleanups
- Try to handle cases where we set a presence, but receive a new
presence event for our account before the server takes notice of that
new presence we want, which probably resulted in the "account keeps
switching between online and unavailable every few sec" glitch
When declining an invite, the popup now offers a checkbox to also add
the sender to the account data m.ignored_user_list event.
This will hide any further invite or message from that user in syncs,
and also immediatly remove the ones we currently have.
As a side-effect, the long-time bug that caused forgotten rooms to
immediatly reappear due to received a "<user> left" event has been
fixed.
For rooms in the room list, when the last message displayed under the
room name is a reply, change the
"In reply to @foo:example.org: original message... ⏎" text shown
before the actual reply content to just "↩ foo: ".
This lets the user preview the actual interesting part of the message,
instead of a long "In reply to" that takes all the available width.
For a message that was a reply to another, and that that started with
a "> ..." quote, the quote wasn't getting highlighted due to regex not
accounting for cases where one is preceded by a </mx-reply> closing tag.
Example, if a room list item subtitle was ">a \n >b", only ">a" was
wrapped with the "quote" class and colored appropriatly due to <a> being
wrapped in a <span> and the regex failing on that
e.g. if someone posts a message containing
"https://matrix.to/#/@foo:example.org", that link will be turned into a
properly colored "@foo:example.org".
Add these characters to the regex allowed list for URL /paths:
non-latin word characters, : ! $ * + ^ @
This also fixes the parsing of matrix.to URLs in messages.
If the application was compiled with QRC (i.e. CONFIG+=dev), a theme
setting that wasn't one of the default theme would fail to be read.
Originally commit cf463f24786566c5ec04a6823e9917975ba2b265,
accidentally thrown out before release
Use a throwaway nio client to make ourself an aiohttp session with proxy
support, that way we don't have to depend on aiohttp and aiohttp-socks
libraries
When the currently shown page is the chat of a certain room,
prevent that room from moving around in the left pane due to new
messages/activity or unread/highlight counters change.
When the user switches to another page/room, the previously held lock is
released and that room completes all the moves it would have done if it
wasn't locked.
This makes navigating a room list with lots of activity easier, and
prevent annoyances like clicking on a room with unread messages and
having it immediatly fly down the list (possibly out of scroll view).
Because of course sound isn't just gonna work on linux and
especially flatpak. Make sure to not spawn an error popup every time
we try to play a notification. Maybe use mpv in the future for
SFX playback (when we'll have a media player implemented),
since it has support for all these backends out of the box.
This happened when we got a message from an account-room pair
where the full member list hadn't been loaded yet, i.e. the user had
never focused the room since starting the client
