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 05524c3f6c5a1a4688ed111b51317970b22fac8e 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>
