Expose commands to the command line & remove keyboard support

[dicktyr]

please consider exposing dunst commands
ideally through the command line interface
(or by extending the DUNST_COMMAND_* format)

I also think key bindings are out of scope for program like dunst
(better to let a dedicated key binder handle that)

in any case
dunst would be more useful if the same commands
which presently require dunst key bindings
were also accessible without key bindings
(so scripts can simply issue commands)

thanks :}

[d125q]

I just wanted to make this request. Additionally, I believe that the majority of dunst users also use things like sxhkd or window managers that allow for custom key-bindings, thus making dunst's key bindings redundant (if the history pop, context menu, etc. commands were exposed).

[tsipinakis]

I guess this needs an update.

We talked this over on IRC and we all agree that keyboard management is out of scope. We decided on the following:

After the release of 2.0 which should be relatively soon, we'll add a new control interface to dunst through dbus outside of the Notification namespace which will replace the current DUNST_COMMAND_* system.

It is subject to be decided whether we will develop a new command line tool to send commands to dunst(e.g. dunstcli -history to redisplay the last notification) or whether it will be built directly into dunst(e.g. dunst -history will send the history command to an already running dunst daemon).

After that is working properly we will deprecate the keyboard support, perhaps by making a minor release that disables it by default and warns the user if they are enabled, and entirely remove it in the 3.0 release. That is the basic idea at least.

The rationale of this is that, as mentioned above, handling keyboard events is the job of the window manager or a hotkey daemon and definitely not relevant to a notification daemon.

Please note that this is still very early and very much subject to change. I'm open to discussion about any part of this plan(even if you disagree entirely, feel free to post your opinion).

[tsipinakis]

Relevant open issues for the reference: #103 #216 #241 #243

[benjamin-thomas]

Hello, I'd love to be able to close notifications via the command line. Not globally but targeted by a specific ID or text content.

As a power user tool, I think it'd make perfect sense.

Would you be willing to consider that use case?

I've been trying to find a workaround, but it seems pretty undoable at the moment.

Unless I'm mistaken the dunst process opens a unique window upon which not much info can be derived with xprop, xwinfo, wmctrl, etc.

[tsipinakis]

Not globally but targeted by a specific ID or text content.

You can already target ids with dunstifys --close=ID flag.

That said, I'd be interested to know the use case for this. It could be done once all this is implemented if it's useful in some way.

[benjamin-thomas]

Excellent! Thanks!!

My use case is a bit out of the ordinary I confess.

I've implemented a couple of scripts to handle my daily routine (too much on my plate), and not satisfied with existing programs.

1. An interactive CLI wrapper around this time tracker tool + hacking it's output
2. An sqlite backed "reminder app" + it's CLI for CRUD stuff

I intend to apply the same design and centralize other background checks, such as server monitoring, triggered business rules, etc. (a quick POC here)

My window manager is i3, and both programs get loaded in their own tmux session upon i3 initialization and are quickly accessible via their own scratchpad (for easy access). In both cases, a background process constantly bubbles up overdue state forcing user action (close and/or reschedule)

If you're curious, here is a screenshot of my reminder tool:

Basically I want this tool to be extremely nagging by design. In this screenshot, once I type ! 8, it removes the reminder #8 from the underlying DB, and I'm going to be able to pop it off dunst's queue at the same time thanks to your suggestion.

[tsipinakis]

Going a bit off topic - but I took a quick glance at your program and you'd probably benefit from using a proper libnotify implementation rather than (ab)using system(), quick googling found this for ruby but there's bound to be more.

From that libraries docs for example, you can directly update notifications and close them via simply n.close.

[benjamin-thomas]

Thanks for the heads up!

I didn't realize that abstraction was available, sorry for the noise!

[ghost]

I'd also like to keep my dunst bindings in sxhkd config. Will there be work on this?

[tsipinakis]

@bebehei seems inactive, or at least hasn't responded to my pings for a while.

It's been a busy time recently so no specific promises, but since it's in a pretty good state currently I'm planning to take over the PR and finish it soon.

[tsipinakis]

Implemented with #651 .