| Summary: | Focus notifying app by click on its notification if the app doesn't set its own behavior for clicking on the notification | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | CTimmerman <ctimmerman2+kde> |
| Component: | Notifications | Assignee: | Kai Uwe Broulik <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kdelibs-bugs, nate, plasma-bugs |
| Priority: | NOR | ||
| Version: | 5.17.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/plasma-workspace/48d3613aa843ba5b27c11cadd4ac85a98fdf280c | Version Fixed In: | 5.18.0 |
| Sentry Crash Report: | |||
|
Description
CTimmerman
2020-01-11 02:47:45 UTC
We leave it up to the app itself to implement this behavior so the app can implement intelligent actions like a web browser going to the tab that sent a notification when you click on that notification, for example, or an email client taking you straight to the new email. If we unconditionally overrode this behavior, clicking on the notification would take you to the browser's currently-visible tab, or the email client's main window Maybe we can add click-to-jump-to-that-app as a default behavior though in case the app doesn't implement any behavior itself. This might be nice for users of apps like KMail that refuse to implement a user-friendly default setting here. What do you think, Kai? Proof of concept patch: https://invent.kde.org/snippets/653 This patch has it activate a window with matching application ID in case the notification doesn't have a default action set. In case of multiple windows it will activate the top most one in stacking order (requires [1] to work). It also then closes the notification. If you could give it a try and see if it fits your workflow that would be appreciated. [1] https://cgit.kde.org/plasma-workspace.git/commit/?id=c0acd1434147cff80de4841c62e766a2bb817c0f Wow, that works perfectly. I think that's just what the doctor ordered! If we add this, and people complain, "I clicked on the notification for a new email but it only opened the email app without showing me the new email" then we'll be on very solid ground to respond with, "That's because only the app itself knows what email to show you when you click on the notification, but the app didn't implement that behavior, so you're getting the default fallback that only knows how to take you to the app's last-used window." Yes, so my original stance still holds: Fix stupid applications. (In reply to Kai Uwe Broulik from comment #5) > Yes, so my original stance still holds: Fix stupid applications. Absolutely. :) I think it is nice to have a better default behavior for apps that aren't yet fixed or refuse to be fixed though. (In reply to Kai Uwe Broulik from comment #2) > Proof of concept patch: https://invent.kde.org/snippets/653 > > This patch has it activate a window with matching application ID in case the > notification doesn't have a default action set. In case of multiple windows > it will activate the top most one in stacking order (requires [1] to work). > It also then closes the notification. > > If you could give it a try and see if it fits your workflow that would be > appreciated. > > [1] > https://cgit.kde.org/plasma-workspace.git/commit/ > ?id=c0acd1434147cff80de4841c62e766a2bb817c0f That's exactly what i want. Thanks! Git commit 48d3613aa843ba5b27c11cadd4ac85a98fdf280c by Kai Uwe Broulik. Committed on 14/01/2020 at 09:59. Pushed by broulik into branch 'master'. [Notifications] Raise application window if no default action is provided FIXED-IN: 5.18.0 Differential Revision: https://phabricator.kde.org/D26622 M +1 -0 applets/notifications/package/contents/ui/NotificationPopup.qml M +64 -5 applets/notifications/package/contents/ui/global/Globals.qml https://commits.kde.org/plasma-workspace/48d3613aa843ba5b27c11cadd4ac85a98fdf280c |