SUMMARY Windows and other systems raise & focus the app when clicking on its notification. KDE doesn't. STEPS TO REPRODUCE 1. Get an email in Thunderbird and/or Evolution for example. 2. Click the notification in the list. OBSERVED RESULT Email client doesn't get focused. EXPECTED RESULT Email client gets focus so i can read the email it notified me about. It would also be nice if the notification disappeared then. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 19.10 (available in About System) KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 ADDITIONAL INFORMATION The dark system bar notification count doesn't stand out like the dark theme one on Gnome 3 does.
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