Bug 429653 - [Feature Request] Notification panel should show buttons or have an ability to resend the notification
Summary: [Feature Request] Notification panel should show buttons or have an ability t...
Status: RESOLVED DUPLICATE of bug 407361
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: 5.20.3
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-25 17:41 UTC by yuannan
Modified: 2020-12-01 18:09 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description yuannan 2020-11-25 17:41:32 UTC
SUMMARY


STEPS TO REPRODUCE
1. Get a notification with buttons. e.g. media controls from music player
2. Wait for it go away or close it
3. Look in the notification panel
4. See that I can't see the buttons anymore
5. Have an existential crisis now having no way to change my music ever again for the rest of time

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.9.10-arch1-1
KDE Plasma Version: 5.20.3-1
KDE Frameworks Version: 5.76.0-1
Qt Version: 5.15.2-1

Would be nice to have this for a lot of apps. I have kdeconnect notifications come in with my messages only later to not be able to reply using the notification panel. Ideally the notification panel would be able to accommodate the buttons and render them correctly but this does sound like a monumental task for a slight quality of life improvement for one user. The ability to resend would be much easier but slightly dirtier approach. If the resend ability is to be implemented it should have a panel to ensure it doesn't piss off other users.

What worries me about this approach of resending instead of displaying:
1) could clog up the panel with duplicate. Settings should be added to have it either: just be a new one (nothing changed about the history logic but have a new notification), only show the old one that has been resent along with the original timestamp (effectively not adding it to the notification panel or change anything having just a visual notification), show the new notification and remove the old one (update old notification), display both but have a marker to indicate it's been artificially resent by the user's request.
2) Could lead to a loop with some scripts that sniff the notifications or some other auxiliary service that has not been accounted for.
3) Clutter if only I want this leading to a ugly UI and wasted dev time

I would love to hear everyone else's opinion on this matter just a small QoL improvement that I thought would be cool to have.
Comment 1 Nicolas Fella 2020-11-25 18:19:07 UTC
To allow invoking actions after the notification closes we need to do quite a bit of rework in how notifications are handled. We have ideas for that, but it's probably going to take a while to get implemented
Comment 2 yuannan 2020-11-25 18:43:56 UTC
(In reply to Nicolas Fella from comment #1)
> To allow invoking actions after the notification closes we need to do quite
> a bit of rework in how notifications are handled. We have ideas for that,
> but it's probably going to take a while to get implemented

Good to know it's in the works :)

Thank you for your great work on this, KDE has been my choice of DE along with i3-gaps for a about a year now. So powerful and yet easy to use. I love the GUI "store" pages for installing extras as well.

If a rework is indeed in the works I think it would be nice to have a hook system (bit like pacman for Arch Linux) for scripters such as myself. Nothing too crazy just a few REGEX functions and the ability to run scripts and call other apps. The current configuration is fairly robust and lovely to use (great work once again to everyone on the team). But it would be cool to have it the script calls come with args. Such as time, caller, notification state, title, description etc.

An example of this that I recently used is from Openvpn with their --up script. Read (Environmental Variables section): https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

The script is ran but passes in lots of vars such as script_type which lets the script know if it's going up or down. This shouldn't too hard to develop and will lead to great work being developed around it for those who a bit more.
Comment 3 Nate Graham 2020-12-01 18:09:12 UTC

*** This bug has been marked as a duplicate of bug 407361 ***