Bug 416107 - Focus notifying app by click on its notification if the app doesn't set its own behavior for clicking on the notification
Summary: Focus notifying app by click on its notification if the app doesn't set its o...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: 5.17.5
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-11 02:47 UTC by CTimmerman
Modified: 2020-01-14 09:59 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.18.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description CTimmerman 2020-01-11 02:47:45 UTC
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.
Comment 1 Nate Graham 2020-01-12 17:00:58 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?
Comment 2 Kai Uwe Broulik 2020-01-12 18:56:35 UTC
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
Comment 3 Nate Graham 2020-01-13 03:22:27 UTC
Wow, that works perfectly. I think that's just what the doctor ordered!
Comment 4 Nate Graham 2020-01-13 03:24:22 UTC
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."
Comment 5 Kai Uwe Broulik 2020-01-13 07:29:26 UTC
Yes, so my original stance still holds: Fix stupid applications.
Comment 6 Nate Graham 2020-01-13 14:21:00 UTC
(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.
Comment 7 CTimmerman 2020-01-14 00:31:46 UTC
(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!
Comment 8 Kai Uwe Broulik 2020-01-14 09:59:32 UTC
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