Open Xylemon opened 9 years ago
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+.)
Been a while since anything related to this issue, hopefully someone could shed some lights on this one. It will be nice to have clickable visual buttons for actions which doesn't require any other input. I will really like to work on this myself, but I barely even know where to start properly.
Any thoughts about implementing it @fwSmit ? giving buttons a bottom layer to notification body seems like a good approach
Been a while since anything related to this issue, hopefully someone could shed some lights on this one. It will be nice to have clickable visual buttons for actions which doesn't require any other input.
Agreed
Any thoughts about implementing it @fwSmit ? giving buttons a bottom layer to notification body seems like a good approach
Your example pictures look good to me. It'll be easy to calculate collision detection with those buttons too. How I would go about implementing this is to first mess with draw.c to draw the button(s) in the right place. After that, you can make the buttons do something by going to input.c and changing the function that handles mouse clicks.
So I tried implementing this and threw my hands up. Atleast I cant implement it with meager skills Ive currently xd
it already looks really good in your screenshot - maybe you could offere your code to review and continue developing on it, by other if you do not like to touch anymore.
I would also like to add, in case other people want to work on it, to base it on the newest master, since a lot of the drawing code has changed and is simplified. This is still a work in progress, though, so it might still change more.
@genofire that was just a reference image, not my actual work. I did went over the source code and imo it will require a lot of refactoring to implement this. I just dont have enough skills and time for it
Infact as @fwSmit said, drawing part of code was really a mess, so its better if someone start it from scratch.
I recently made buttons on a project of mine so I have a clear idea on how to do it. However it is not a easy feat, especially making this the right way. Is this feature still wanted?
It would be better to come up with a clear specification for these buttons so that we can avoid having half-assed implementations.
Wanted: yes. And it would prevent me to find search yet another notification daemon, as i pretty much like dunst.
PLZZZ
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.