Telegram listens for a signal that indicates when the color-scheme
changes. The signal itself includes the new value, but Telegram
currently queries for the value immediately after getting the signal.
This second round-trip is unnecessary, since the signal itself contains
the same information.
This changeset avoids this follow-up query, and drops the now-unused
`Setter`.
If the notification daemon is an activatable GApplication service (e.g.
on Mate), then the notification daemon may terminate a short time after
the notification has vanished (usually 15s). In that case the
notification daemon may reuse notification IDs, which is incompatible
with our notification clearing.
Also the service may not be running at all, when we call the
CloseNotification endpoint.
To fix this, we simply disable the entire notification history clearing
functionality on such desktops by proactively clearing all notification
references from our internal notification manager.
Signed-off-by: Magnus Groß <magnus.gross@rwth-aachen.de>
In general we need to keep a reference to the notification id, so that
we can delete the notification later from history - unless the
NotificationClosed reason was that the user actively dismissed it, in
which case it is not kept in history anyway (so we can dismiss our
reference too).
-- Background --
Some desktop environments such as KDE keep a history of notifications.
An API is provided to delete notifications from that history by calling
the org.freedesktop.Notifications.CloseNotification endpoint with the ID
of that notification. If the notification was already closed (timed
out), then this will delete the notification from history.
The intent is to clear these notifications from the notification history
as soon as a chat with notifications originating from that person is
opened, as the user is then not interested anymore in those
notifications and to prevent unnecessary clutter in the history widget.
It is also cleared when the chat is read on another device.
-- Problem --
Telegram already has all the code in place to support this
functionality, but unfortunately this did not work on Linux before,
because we listen to the NotificationClosed signal and remove our
reference to the notification id from our internal manager as soon as we
get that signal. This means that we do not clear that notification from
history once we open the chat with that person (unless we open the chat
before the notification has timed out, i.e. if we didn't get the
NotificationClosed signal).
-- Fix --
To fix this, we keep our notification reference (if the notification was
not dismissed by the user), which means that our reference will be kept
around until we open the chat with that person (or close Telegram
entirely).
Since all the needed functionality for deleting notifications was
already in place, this patch is quite short as we only need to keep the
reference around longer than we did before this patch.
Note also that code is already in place to clear notifications for
messages that were read on another device: History::inboxRead() calls
Core::App().notifications().clearIncomingFromHistory()
Fixes#17111
XDG is inventing new tray specification, so SNI will be outdated soon and it's better to just use QSystemTrayIcon.
I believe all the major drawbacks of QSystemTrayIcon are solved and we can live with minor ones.
Given the planned MainWindow refactoring, it seems it's the best time to do that.
QApplication has a historical feature[1] of calling setlocale(3) at init,
which today cause more harm than good. Such call isn't thread safe neither
per C standard, not per any known libc implementation. The Gio threads
would call into locale reading functions all the time, so early access to
locale by Gio may race with setlocale() by Qt leading to undefined behavior.
Platform specific start before the Sandbox (aka QApplication) is at core
design of tdesktop and that order can't be changed. There is no way to pause
Gio until QApplication instantiates.
Fortunately, Qt library itself has a static global flag that prevents it
from calling setlocale() twice. We don't even need to instantiate a
temporary QCoreApplication, we can just call into the method. So call
it form Platform::start before any existing or future calls to Gio.
Fixes#16922
[1] https://chat.stackoverflow.com/rooms/63812/discussion-between-phil-armstrong-and-matteo-italia
23rd
Sergey A. Osokin
Hugo Osvaldo Barrera
Ilya Fedin
Magnus Groß
John Preston
Klemens Nanni
Gleb Smirnoff