New command line control

[bebehei]

We should write a command line control for dunst.

Currently, control takes place only via keyboard and a some hackish way via notifications. These notifications are effective, but quite ugly and the keyboard shortcuts are not working on some environments.

I propose to add a new binary, which can send commands to the dunst server via an additional DBus interface.

The features, this command line tool should have:

• close one/all notifications
• pop history
• pause/unpause/toggle dunst
• retrieve information about notifications
• ... ?

This would in addition fix/invalidate all of these issues.

#308 #307 #216 #171 #103 #112 #138 #284 #241

[tsipinakis]

Duplicate/relevant: #284

[bebehei]

I started work on it: https://github.com/bebehei/dunst/tree/dunstcmd

dunstcmd status is already working in a preliminar form.

[ckipp01]

Hey! Thanks for all the work on this. I've seen this issue linked from quite a few others. Is there a status update on the ability to be able to query whether or not dunst is paused or not? I've recently switched to dunst and normally just have a toggle switch to switch on or off notifications. It's sort of killing me that there seemingly isn't a good way to query for that info in dunst.

[tsipinakis]

Not much to update, it's on the roadmap but the progress is only what you see on the branch above. I'm not sure if @bebehei is still planning to work on this.

[bebehei]

Yes, I had been on it. But in the meantime, I actually don't know whether I'm finishing the client side in C. The current architecture for the client is ugly. I'd actually prefer Python for the client (or have a try with Rust).

On the server side, the problems are solved and the architecture is clear. The intended feature set is not yet implemented on the server side, but that's an easy game.

[bebehei]

The server side is "finished". I dropped the C-client. @Stunkymonkey will finish the client side. We've settled with Rust.

[tsipinakis]

That's awesome, I've been trying to learn rust recently and this is yet another excuse to get to it.

Is there a repo set up somewhere for it? (Or are we putting it in here along with everything else?)

[bebehei]

Is there a repo set up somewhere for it? (Or are we putting it in here along with everything else?)

There is a project, but it's currently hidden and just for test usage.

Idk if we should put it into the main repo. We actually should be client agnostic and we're adding a shitload of compilation dependencies by choosing Rust. But on the other hand side, If we won't ship the client, nobody will ever use it.

[Stunkymonkey]

so the first prototype is working:

• closing one notification
• closing all notifications
• redisplay notifications
• open context menu
• get status of dunst
• set status of dunst
• listen status of dunst

the error handling is done for arg-parsing, but not for dbus.

now we have to discuss where to put the code. yes it would add a lot of dependencies, but I think otherwise it will not be used, because the installation is an extra step.

[bebehei]

Publish! publish! publish! 🎉

[tsipinakis]

Yay! I think it's ready for a published first version! 🎉

---

About where to put it, I don't have a clear opinion yet, I'll just put my train of thought based on the arguments mentioned so far here and wait some feedback before I solidify it.

If we put it in this repository:

• We'll be adding a ton of extra dependencies + a whole new compilation system for the rust crates which could annoy many, and complicate the packaging process
  • On the other hand this would only affect those building from source and maintainers, since rust statically links most things
• It will be more visible and used more often because it'll get installed alongside
  • True for those building manually, but we could also pass a hint to the downstream maintainers to install it alongside (In debian there's Recommend-ed packages which are installed by default unless disabled)

If we split it out into a different project

• We'd be encouraging development of alternate clients (good)
• It may not be available in distros for a long time, reducing usability.

[Stunkymonkey]

It may not be available in distros for a long time, reducing usability.

I think this is the major disadvantage.

We'd be encouraging development of alternate clients (good)

Do we really need alternative clients? The dbus interface would not be documented, but if someone needs access to it can be looked up through code. Mostly the feature-set would be the same in the end, because it is limited by the dbus methods and propertys.

[bebehei]

To me, the second paragraph is absoultely new to me. I never thought about it this way. But it's actually the absolute killer argument: I don't want to document the DBus Interface and write a new API docs for it.

[tsipinakis]

That's a good argument indeed. However we should treat changes to the dbus interface as backwards incompatible/avoid them where possible to avoid affecting those that do want to use it.

[bebehei]

That's a good argument indeed. However we should treat changes to the dbus interface as backwards incompatible/avoid them where possible to avoid affecting those that do want to use it.

Well yes, this is easy. We just have to proceed with our interface name. It's a common style to suffix the DBus Interface name with an incrementing number, starting with 0.

So, we just increment the number on backwards incompatible changes. And alternative clients will intentionally break until the breaking changes are considered.

[Stunkymonkey]

here it is my dummy repo

[tsipinakis]

After taking some time to think about it I also support merging it in this repo, with all said above considered the main argument that made me solidify it is that most if not all users will want some type of shortcut to control dunst and given that we're deprecating the keyboard shortcuts this will be the only way to do it.

[Stunkymonkey]

it is still a big question if settling with rust is the right idea. The little program i wrote works fine, but adds a lot of dependencies.

[tsipinakis]

That's my one remaining concern, this looks like a very thin and simple client to warrant a new language and build tools.

@bebehei Why did you give up on writing the client in C in the first place?

[Stunkymonkey]

maybe a bash script could be enough.

dbus-send --print-reply --dest=org.freedesktop.Notifications /org/freedesktop/Notifications org.dunstproject.cmd0.NotificationCloseLast

this can do the same thing my programm is doing

[bebehei]

@tsipinakis I mainly gave up writing the client in C, because it's just overhead, overhead, overhead, overhead, overhead and then a few lines of code, which are actually crucial.

A few stats: In the dunstcmd branch, I created the client files, which had ~500 LOC of C. And I had only support for the status. @Stunkymonkey implemented almost everything in <200 LOC of Rust.

To achieve a proper subcommand structure, I had enormous overhead. It started to feel wrong even when I initially started the client. And looking at the code again, I'm confident to say: C is the wrong language for the client.

I'm not yet confident to say Rust is the right language for the client. I'm pretty unsure, if bash is suited better as the client. If I had to choose a language now besides Rust, it might be python.

[tsipinakis]

Ok, looking at the code myself now I have to agree that's a lot of overhead for little functionality. C is obviously way too much here.

I'd be hesitant to use bash because IMO it limits our ability to expand this out further if needed. The complexity of bash scripts tends to increase exponentially as features are added.

Like you, I'm also unsure of the language to choose now, python seems like a good fit as, the only downside would be the added runtime dependencies (to python-dbus and most likely a few more).

[Stunkymonkey]

i would still prefer posix-shell.
python is installed everywhere in a different version, which could lead to problems.

[Stunkymonkey]

I am not sure if we will enhance it with many features in the future. The amount of keyboard shortcuts was also not increasing over time.
Right now I am writing a shell-script to show, that not much is needed.

[Stunkymonkey]

have a look at https://github.com/Stunkymonkey/dunstctl/blob/master/dunstctl
90 loc and nearly the same functionality

[tsipinakis]

Huh, that managed to change my mind. I actually prefer that a lot more than anything else proposed until now.

If anything, it's just shell so we're not adding any extra dependencies - if we hit some issue we can always re-write it since it's that simple.

[bebehei]

I've currently taken it under revision and pack it into my branch. A PR will follow probably tomorrow.

[process0]

It would be useful if we could get the number of notifications received for when dunst is muted.

[tsipinakis]

The initial implementation of this was merge in #651, so I'll close this. Any other feature requests should be separate issues.