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.
Previous assertion violations because of NaN from std::round were
in video streaming, see commits 27d58ba07b, 8f5830d520.
Now the crashes happened in the ConvertScale() call from a background
thread when preparing an image from clipboard for sending to a chat.
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
When Wayland support for global menu was added (0b86feeeb5), X11 support was broken since QWindow::winId returns WId what is a quintptr that expands to uint32 on 32-bit and to uint64 on 64-bit, while AppMenu d-bus service accepts only uint32.
