Query number of notifications? about linux_notification_center HOT 9 OPEN

Hi @luigibarbato, atm I don't have time to build any new features. It would be a really cool feature to have, though. Community contributions are very welcome 😉

from linux_notification_center.

I have the exact same use case; being able to query the number of notifications would be excellent.

Maybe it would suffice to add a notificationUpdateCommand option, which, similar to the existing startupCommand, defines an optional command to run when the set of notifications is updated, passing the number of notifications as an argument to the commmand? This is a little hacky, but would be simple to implement and flexible to use.

from linux_notification_center.

I rly would love to do something like this, but I'm struggling to see how we'd get info from deadd when it's running. It'd be kinda lame to ship a binary that just does communication with deadd.

Maybe we could try to hijack the --action infrastructure somehow so we could just use notify-send.py? This feels mega hackey, but I guess it could work.

An even jankier solution would be to allow the user to specify a file that deadd would write to when it gets certain commands. This way, you could query deadd by just doing --hint boolean:deadd-notification-center:true, and checking the contents of the file. This is very scripty, which is nice, but it still feels kinda weird. I don't know of many programs that do this.

It might make the most sense to do communication via a seperate binary TBH. It could communicate via IPC ports, or even via a specialized DBUS service. We might even be able to code in more advanced features, like the ability to retrieve notif text, or maybe to modify notifs from the command line. This is similar to i3-msg, I suppose.

from linux_notification_center.

Looking back over this, I do really like @wbthomason's idea of a command that maybe pings i3blocks whenever the number of notifications changes. In this script, we could even extend the environment with things like a list of noti ID's, and maybe a json array of noti's and their content.

I still think it'd be a nicer solution to provide a seperate binary, but this would definitely allow us to cut down on the packaging bloat. Do any of you have any preferences for the solutions laid out?

from linux_notification_center.

Either my proposed solution or the external i3-msg-like binary seem reasonable to me.

from linux_notification_center.

Alright, well I think an i3-msg-like tool would be cool. We could accomplish this via Unix domain sockets.

from linux_notification_center.

We also could extend the dbus protocol for notifications! That might be the best and cleanest possible way. Any good ol python script could them just query the number over dbus. Only downside might be, that I am not sure how pushing the number instead of polling would work. Had to look inside this to find out.

from linux_notification_center.

Yeah, I've been thinking about this, since I've been playing around with dbus a bit more recently. DBus is definitely the way to go, although I think it might be worth considering shipping a binary that can interface with dbus on the user's behalf, so the user wouldn't have to write their own python scripts to do what they want, at least for simple get-style or set-style requests.

This would also present a good opportunity for some other stuff, such as:

• writing better documentation (we're using dbus now, which means it's technically an API that we should expect users to want to use).
• Adding existing IPC-related flows to DBUS. This includes:
  • Noti Center Toggling
  • Setting & Getting state of user defined button
  • Pause / Unpause popups

Something that I also think we should do is support hooks (via add_signal_receiver, and possibly something like PulseAudio's !ListenForSignal).

This might support a number of interesting use cases. For example, users could implement dameons that wait around monitoring user-defined button states, and could automatically unclick buttons that the user deems to be single-use (instead of toggle buttons, which is effectively the default behavior). Currently, this 'unclicking' logic would have to be specified in the user's config file (specifically, the command that's run), but putting it there means dealing with an increasingly awful colon-separated list syntax (see #80 (comment) for alternatives to this).

Resources and relevant links:

• https://dbus.freedesktop.org/doc/dbus-api-design.html

from linux_notification_center.

We have news about this amazing feature or is in backlog?

from linux_notification_center.