Created attachment 152492 [details]
Example of how notifications look with "resident" forced to "true"

I agree 100%. See also Bug 407667.

Wanna submit a merge request to do this?

There's a massive difference between what your saying happens and the spec.

" When set the server will not automatically remove the notification when an action has been invoked. The notification will remain resident in the server until it is explicitly removed by the user or by the sender. This hint is likely only useful when the server has the "persistence" capability. "

I don't see how that corresponds to the previous concerns especially about "race against time" to click things or how anything looks. The spec implies it shouldn't change the time at all.

We might be doing something inappropriate with the hint that needs identifying and fixing, but blinding changing does not seem the way to go.

I don't think this is something we can do. Apps expect a specific behavior depending on whether resident is set or not, we can't just change that without potentially breaking apps

To give one example: KNotifications deletes the client-side KNotification object when the notification is closed (unless the notification is marked as resident). If the server would start to treat it as resident and don't close it then the object would never be deleted, leaking memory

Created attachment 152494 [details]
A Discord notification with the "resident = true" hack applied

(In reply to David Edmundson from comment #4)
> There's a massive difference between what your saying happens and the spec.
> 
> " When set the server will not automatically remove the notification when an
> action has been invoked. The notification will remain resident in the server
> until it is explicitly removed by the user or by the sender. This hint is
> likely only useful when the server has the "persistence" capability. "
> 
> I don't see how that corresponds to the previous concerns especially about
> "race against time" to click things or how anything looks. The spec implies
> it shouldn't change the time at all.
> 
> We might be doing something inappropriate with the hint that needs
> identifying and fixing, but blinding changing does not seem the way to go.

I will use Discord as an example of what happens. When you get a Discord message, be it a tag, direct message, or otherwise, you will get a notification on your desktop. When this notification appears as a popup on Plasma, you are able to click this notification, upon which the Discord client will be focused, and it then navigates you to the part in the application where that message was received (either a channel on a server you're a member of, or a DM conversation).

Currently however, clicking the notification while it is in its popup state is the only way to evoke this functionality. Once the notification expires and sits in the notification applet, it is no longer clickable, and it does not present any buttons to interact with either. Its functionality is therefore lost.

The hack I did on my system, is to edit `libnotificationmanager/notification.cpp` and change the line that reads `resident = hints.value(QStringLiteral("resident")).toBool();` to simply `resident = true;` - just to see what happens.

Upon performing this hack, the Discord notification within the notification applet now has a little button added to it (see screenshot). Upon clicking this button, I am brought to the place within Discord where the message in question originated. In other words, the functionality which was previously lost upon expiry of the notification popup is now restored.

In the case of Discord however, clicking the "View" button only works once. Any subsequent clicks have no effect. Some other applications are similar in this behavior, some are not. In other DEs (using GNOME & Windows as reference), it is common practice to remove the notification from the history once it has been interacted with, perhaps we could do something similar here.

If the "resident" property is not the right point to edit here, then let it be something else. The point of this issue isn't to change how "resident" functions necessarily, it is simply to retain the functionality of the vast majority of notifications once their initial popup has expired.

It sounds like you're using this hack as a workaround for the lack of Bug 407667? Can we fix that without doing this?

Using the resident hint is the correct fix for https://bugs.kde.org/show_bug.cgi?id=459774, but it's something that applications need to support, not something we can hack into Plasma

*for https://bugs.kde.org/show_bug.cgi?id=407667

(In reply to Nate Graham from comment #9)
> It sounds like you're using this hack as a workaround for the lack of Bug
> 407667? Can we fix that without doing this?

I'm using it as a workaround for https://bugs.kde.org/show_bug.cgi?id=407361 actually. 407667 only suggests to focus the app, this hack provides full functionality of the initial popup.

Why can't we just make expired non-resident notifications clickable in the history view, such that clicking on them launches or activates the app that sent the notification? It won't be perfect since it couldn't take you to exactly the page or view that's relevant to the notification, but it would be better than nothing.

(In reply to Nate Graham from comment #13)
> Why can't we just make expired non-resident notifications clickable in the
> history view, such that clicking on them launches or activates the app that
> sent the notification? It won't be perfect since it couldn't take you to
> exactly the page or view that's relevant to the notification, but it would
> be better than nothing.

I think this would lead to confusion more than anything. Users wondering why when "sometimes" they click the notification they get to the proper part in the app, and "sometimes" they don't. Many likely won't make the connection that notifications in the applet vs. popup behave differently, leading to a frustrating experience.

I've submitted a much-less-hacky implementation here: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2178

This does not touch resident functionality at all and should therefore mitigate any potential issues as mentioned by Nicolas.

*** Bug 460350 has been marked as a duplicate of this bug. ***

Regarding the implementation, I was under the impression that the hints boolean values, which include the "resident" and "transient" values, worked like this:

- Resident: the notification is not dismissed until the user manually closes it. Similar to permanent notifications on Android.
- Transient: the notification is automatically dismissed and furthermore, is not stored in the tray when it times out.

Our issue currently comes with the behavior for the default case (no resident hint, no transient hint either), which seems to be left up to each implementation as per the specs. (See https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#hints ). They explicitly state that "Neither clients nor notification servers are required to support any hints". However, besides of these boolean values there's also the urgency level, which does include a recommended implementation cue - regarding critical urgency notifications, "They should only be closed when the user dismisses them, for example, by clicking on the notification."

(In reply to Carlos Solís from comment #17)
> Regarding the implementation, I was under the impression that the hints
> boolean values, which include the "resident" and "transient" values, worked
> like this:
> 
> - Resident: the notification is not dismissed until the user manually closes
> it. Similar to permanent notifications on Android.
> - Transient: the notification is automatically dismissed and furthermore, is
> not stored in the tray when it times out.
> 
> Our issue currently comes with the behavior for the default case (no
> resident hint, no transient hint either), which seems to be left up to each
> implementation as per the specs. (See
> https://specifications.freedesktop.org/notification-spec/notification-spec-
> latest.html#hints ). They explicitly state that "Neither clients nor
> notification servers are required to support any hints". However, besides of
> these boolean values there's also the urgency level, which does include a
> recommended implementation cue - regarding critical urgency notifications,
> "They should only be closed when the user dismisses them, for example, by
> clicking on the notification."

That's correct. I do apologize for the confusion, because the problem I've outlined isn't actually that notifications aren't "resident" by default (although this would solve the problem at the cost of producing others), but simply that they lose their interactive functionalities once the popup disappears and they are stored in history only.

Resident notifications aren't expired the same way "normal" notifications are, which is why they keep their interactive features - therefore I initially thought making all notifications resident should be the default behavior.

The implementation I've submitted seeks to establish a middle-ground of sorts, by initially treating "resident" notifications and those with interactive features the same way: To not formally "expire" them when the popup is gone, but rather mark them expired, so the popup disappears, but the notification is technically kept open.

The treatment of notifications then differs: Resident notifications are kept open no matter how many times a user interacts with them (as was the case before), but regular notifications are then properly expired (because most seem to lose their functionality after one interaction anyway). This then also causes any interactive buttons in the history to disappear (since they would lose functionality anyway most of the time).

There is currently one situation in which this would produce an unexpected result however: If the application that fired an interactive notification (e.g. Discord) is closed before the notification has been interacted with, the interaction would of course not produce any results, since there is no client to handle the event.

See https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2178

Git commit 412fa14afa663a3845ca6cbd21b47f602e7cfa00 by Nate Graham, on behalf of Dominique Hummel.
Committed on 27/03/2025 at 18:02.
Pushed by ngraham into branch 'master'.

Keep notifications usable in history

This patch aims to solve the below bugs by introducing a new prop to the notification
object called `hasSomeActions`, which as the name implies, is `true` if said notification
object has any usable actions.

Upon expiry, notification popups that have actions attached to them will be kept "open"
in order to preserve functionality within the notification applet (the history), without
requiring the "resident" hint to be present.

Said notifications will still be closed upon interaction or manual dismissal by the user
(either individually or through the cleanup action), as well as expired properly when the
owning application exits. Functionality regarding the "resident" hint is untouched.
Related: bug 407361
FIXED-IN: 6.4.0

M  +28   -27   applets/notifications/package/contents/ui/FullRepresentation.qml
M  +7    -0    applets/notifications/package/contents/ui/components/ActionContainer.qml
M  +2    -2    applets/notifications/package/contents/ui/components/FooterLoader.qml
M  +4    -0    applets/notifications/package/contents/ui/components/ModelInterface.qml
M  +6    -2    applets/notifications/package/contents/ui/global/Globals.qml
M  +21   -0    libnotificationmanager/abstractnotificationsmodel.cpp
M  +8    -0    libnotificationmanager/abstractnotificationsmodel_p.h

https://invent.kde.org/plasma/plasma-workspace/-/commit/412fa14afa663a3845ca6cbd21b47f602e7cfa00

*** Bug 493701 has been marked as a duplicate of this bug. ***

*** Bug 489820 has been marked as a duplicate of this bug. ***

*** Bug 486046 has been marked as a duplicate of this bug. ***

*** Bug 500860 has been marked as a duplicate of this bug. ***

*** Bug 447389 has been marked as a duplicate of this bug. ***