| Summary: | Make "resident" notifications the default. | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Naxdy <xnaxdy> |
| Component: | Notifications | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | ASSIGNED --- | ||
| Severity: | wishlist | CC: | csolisr, gabriel1rodrigues2, kde, kde, nate, nicolas.fella |
| Priority: | NOR | Keywords: | usability |
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=407361 https://bugs.kde.org/show_bug.cgi?id=407667 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Example of how notifications look with "resident" forced to "true"
Example of how notifications look with "resident" forced to "true" A Discord notification with the "resident = true" hack applied |
||
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 (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. |
Created attachment 152491 [details] Example of how notifications look with "resident" forced to "true" Currently, a lot of notifications lose some or all of their functionality after moving from the standalone notification popup into the notification applet. As I understand, the idea is that if notifications contain a "resident" hint, indicating to plasma that this functionality should be preserved. In my opinion, this should be an opt-out rather than an opt-in (as it currently is). As it stands, only a very small minority of applications actually opt in to this functionality. Those that do not are clearly missing functionality once their notifications move into the applet. This creates a sort of "race against time", where a user might feel pressured to click on the notification as soon as possible, or drastically increase notification timeout, lest they will be unable to navigate to the notification's origin as easily. Prime examples here are messaging apps such as Slack or Discord, where the notification is designed to bring you to the relevant chat immediately. Once this functionality is lost, navigating to the relevant channel can become a chore, since you will either have to rely on the application's internal notification system (e.g. Discord's inbox) or even navigate completely manually. What adds additional frustration is that Plasma seems to be one of the only shells that exhibit this behavior. The GNOME shell, as well as the Windows desktop both preserve full notification functionality even once the initial popup has been dismissed (be it manually or automatically). This makes Plasma a clear outlier in this situation. For experimental purposes, I have compiled my local `plasma-workspace` to ignore the "resident" hint, and always display the additional functionality. Without any further modifications, this results in the aforementioned functionality being restored in form of a button. The label of said button appears to be different for each application. Discord & Slack use "View", whereas Thunderbird uses "Activate". Furthermore, for some applications, the button loses functionality after the first press, whereas for others, it continues to work indefinitely. As such, if we decide to enable the "resident" behavior for every app, it would be appropriate to dismiss the notification automatically once this button has been pressed, as this behavior would be intuitive anyway. I've attached some screenshots of my local notification applet with the "resident" hint forced to "true" for every app. Even in its current state, it has already improved usability of the notification applet tremendously for me, and I no longer feel pressured to click on every notification as soon as possible. Alternatively, if we do not want to force this behavior for every app, I suggest making it a user-configurable option either in the applet or system settings. This way, users can keep the current behavior if they so choose.