The Qt documentation says:
This is the file name, without the full path or the trailing ".desktop" extension of the desktop entry that represents this application according to the freedesktop desktop entry specification.
Qt 6.5.2 also automatically fixes it breaking all the current tdesktop and desktop-app usage expecting the file extension.
As there are notification daemons with quick reply support and GNotification API having mandatory default action support now, it's the time to reconsider button arrangement.
This also makes it possible for legacy notification daemons without default action support opening the chat when no buttons are allowed since 05524c3f6c again.
That's a much better way to avoid defunct event loop that will work in any edge case
Also don't assume GApplication is always running in Platform::Notifications::Enforced
The UX is not the best without sound, so there's no advantage in using GNotification on GNOME.
Remove mention about being native to GNOME as it's not true anymore.
It's used if there's a gtk notification daemon or application is running sandboxed without access to the freedesktop protocol.
GNotification API is poor, but should feel native on environments using GNOME technologies.
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
