| Summary: | Do something sensible when clicking on the background of a notification with no default action specified | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | leftcrane <leftcrane> |
| Component: | Notifications | Assignee: | Kai Uwe Broulik <kde> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | elypter, jonas.harer, kdedev, lfritzsche1990, nate, plasma-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | 5.23.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
leftcrane
2019-03-19 12:14:24 UTC
"I think it may even be a good idea to make sure that clicking on the body of the notification behave the same way as this proposed shortcut" This would be especially relevant for new users who aren't familiar with the shortcuts. some of them wont even close when you act on them - like chromium notifications alternatively it could be closable by a 2 finger swipe to the left on a touchpad which is treated as a left scroll. it already closes on swiping left on a touchscreen like on android. swiping right could pin it, save it for later or perform an action. alternatively a double click could be used to close as well. the middle click could be used for alternative actions. notifications with 2 or more options could use swiping left or right for the major 2 options and indicate that possibility with arrows on the buttons > What's worse is that some of them stick around for a while before disappearing. To dismiss them you have click on the tiny x in the popup, which is not ideal. This is a separate issue; see Bug 413203. > some of them wont even close when you act on them - like chromium notifications This is still another separate issue; see Bug 464982. The challenge is: what's sensible? If the app is running, we can focus and raise its window. But what the window is showing may not be relevant to what the notification was about. In this case, is it really sensible? The same goes double if the notification is in the history and the app isn't running anymore: all we can do is launch the app, but then there's no guarantee that the view it shows on launch will be related to the contents of the notification. What would folks propose we do here? *** Bug 503126 has been marked as a duplicate of this bug. *** Comment from the duplicate: lfritzsche1990@gmail.com 2025-04-21 16:59:29 UTC Example: clicking on a notification from discord. Expected behaviour: Discord should open if not allready, relevant server and channel should open and it should scroll to the message. Actual behaviour: Nothing, seems like it doesnt even detect im clicking on the notification, as it should automaticall close itself after being clicked on. > Discord should open if not allready, This is something we can do in Plasma as a fallback for when the app doesn't implement anything sensible here. > relevant server and channel should open and it should scroll to the message. This is something we *cannot* do in Plasma; Discord itself would have to implement this behavior. But *Discord* for example, clearly has something implemented there, as every other DE under the sun reacts as expected when you click a notification from it, same as other applications like for example notifications from chrome open chrome and then a new tab go to a URL. Other notifications can be purely informational tough. So there must be *something* that the application is sending to implement this behaviour and plasma is just not supporting it,no? I don't believe that the Cinnamon DE as an example where this aspect works beautifully, has a custom script that parses the notifications content to force some behaviour on interaction. It would be ridiculous to have a custom script for each individual application, there must be some generic way other DEs like mint for example implement this *** Bug 508565 has been marked as a duplicate of this bug. *** In the latest duplicate, it was pointed out that the notifications do something in GNOME. (Others mentioned they do things in other DEs as well). It's worth seeing what GNOME does as inspiration here as a starting point. (In reply to TraceyC from comment #12) > In the latest duplicate, it was pointed out that the notifications do > something in GNOME. (Others mentioned they do things in other DEs as well). > It's worth seeing what GNOME does as inspiration here as a starting point. In the current 6.4.3 you guys have implemented a "view" button on interactive notifications in history, and other buttons (if applicable) hidden behind a menus button) Would it be possible to: On notifications with a single button to execute the buttons action when clicking any area on the notification in history? (eh. do away with the button, make it more seamless) Notifications with multiple buttons should open the context menu instead. Also, if done with R-click it should do the above WITHOUT marking the notification as read and therefore not removing it from notification history |