[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Naxdy changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #19 from Naxdy --- See https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2178 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Nate Graham changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=407667 Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #18 from Naxdy --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Carlos Solís changed: What|Removed |Added CC||csol...@azkware.net --- Comment #17 from Carlos Solís --- 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." -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Nate Graham changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=407361 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Nicolas Fella changed: What|Removed |Added CC||gabriel1rodrigu...@gmail.co ||m --- Comment #16 from Nicolas Fella --- *** Bug 460350 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #15 from Naxdy --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #14 from Naxdy --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #13 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #12 from Naxdy --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #11 from Nicolas Fella --- *for https://bugs.kde.org/show_bug.cgi?id=407667 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #10 from Nicolas Fella --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #9 from Nate Graham --- It sounds like you're using this hack as a workaround for the lack of Bug 407667? Can we fix that without doing this? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774
--- Comment #8 from Naxdy ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #7 from Naxdy --- Created attachment 152494 --> https://bugs.kde.org/attachment.cgi?id=152494&action=edit A Discord notification with the "resident = true" hack applied -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #6 from Nicolas Fella --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #5 from Nicolas Fella --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Nicolas Fella changed: What|Removed |Added Status|CONFIRMED |REPORTED Ever confirmed|1 |0 CC||nicolas.fe...@gmx.de -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 David Edmundson changed: What|Removed |Added CC||k...@davidedmundson.co.uk --- Comment #4 from David Edmundson --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Nate Graham changed: What|Removed |Added Keywords||usability --- Comment #3 from Nate Graham --- Wanna submit a merge request to do this? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 Nate Graham changed: What|Removed |Added CC||n...@kde.org Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #2 from Nate Graham --- I agree 100%. See also Bug 407667. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459774] Make "resident" notifications the default.
https://bugs.kde.org/show_bug.cgi?id=459774 --- Comment #1 from Naxdy --- Created attachment 152492 --> https://bugs.kde.org/attachment.cgi?id=152492&action=edit Example of how notifications look with "resident" forced to "true" -- You are receiving this mail because: You are watching all bug changes.
