I know dunst has a context menu that can be activated by a key combination, but I honestly miss how other notification daemons had clickable buttons inside the notification itself. So could there be an option for buttons on notifications? I don't care if you do it via GTK or some other method, anything that just shows the actions and buttons for them is enough for me.
What do you mean ?
Maybe you mean something like a systray?
E.g some icon, where you click on it and the messaglist appears?
I would desire something similar to other notification daemons like xfce4-notifyd where there is a button on the notification itself for an action (or actions) that you can click. An image I found off a quick Google search to show what I mean: https://3.bp.blogspot.com/-vfPYETQBckQ/UiOXdAZYQdI/AAAAAAAAKnM/x1MdKs3ygBw/s1600/nuvola3.png
Another example of a program that you could test this out with is Pidgin. As with other notification daemons, when someone would message me I would always have a "Show" button to click on and it would bring up the message window.
The other notification daemons utilized GTK2 for the buttons, but dunst doesn't have to go that far. Just an option to have these buttons would satisfy me.
I think being able to click the notification to bring up the action menu (i.e. allow clicks to do exactly the same thing as Ctrl+Shift+. does now) would be a good simple improvement.
As a simpler alternative, perhaps a middle click on a notification with an associated action or URL should invoke it. This would only really make sense if there is just a single associated action, or if some action could be determined as the default. But even if it only works in the simple case of one action, it would be very convenient in my opinion.
I would be willing to write a pull request for this.
if some action could be determined as the default
Quoting directly from the notification spec:
The default action (usually invoked my clicking the notification) should have a key named "default".
I'd gladly accept a PR implementing this if it doesn't break backwards compatibility.
I think the best way to handle this is to have middle click invoke the default action if available and then attempt to open the context menu if not.
I'll also consider implementing the button feature, but that's more on the long term and there are still some issues that need to be solved before any serious work on new feature implementation is done.
Anyway to change middle click to left click?
Not from the configuration for now but if you're fine with patching it yourself this should work:
diff --git a/src/x11/x.c b/src/x11/x.c
index 1ca3243..2b2d8bd 100644
--- a/src/x11/x.c
+++ b/src/x11/x.c
@@ -916,7 +916,7 @@ static void x_handle_click(XEvent ev)
}
if (n) {
- if (ev.xbutton.button == Button1)
+ if (ev.xbutton.button != Button1)
notification_close(n, 2);
else
notification_do_action(n);
Thank you @tsipinakis
Arch Linux patch, I will be glad if anyone test.
Are there any new informations?
I found dunstify -A yes,ACCEPT -A no,DECLINE "Call waiting" which works (a little bit ugly - but better then nothing)
It seems configurable mouse events have been added, any chance of
1) visual buttons (main request of this issue)
2) a mouse action that always displays the context menu (like Ctrl+Shift+.)
Most helpful comment
I think being able to click the notification to bring up the action menu (i.e. allow clicks to do exactly the same thing as Ctrl+Shift+. does now) would be a good simple improvement.