psuedodaemon brainstorm

[budRich]

I haven't really tested, maybe it isn't a problem, but i fear that with this new queuing of messages, it might get a bit complicated if one would do something like:

herbe -x 500 "msg1"
herbe -x 1000 "msg2"
herbe "msg3"

That was actually my main motivation adding the commandline-options ( #3 ), having different geometry for different notificatoins. I have been experimenting a bit with a flow like this:

tl;dr as long as a notification is visible a daemon and socket is open

herbe "msg1" 
# will start a herbe daemon and open a "local" socket, and start a timeout timer, 
# when time is up, notification, daemon and socket are killed

herbe -t 10 "msg2"
# if the daemon is running, -t 10 and "msg2" is sent to the daemon via the socket, 
# "msg2" notificatoin will get created and displayed immediately, 
# and "10 seconds would get added to the current timeout". (kind of)

Benefit of doing it this way is that herbe by default will be "executed in the background", like dunstify. But it will be easy to also add a --block option so that execution of herbe command will terminate when the notification is terminated. It will also be easy to add an ID system, so one can emulate f.i. dunstify --replace ID which is a feature i use a lot with dunstify.

It will however make the program a little bit more complex, but not that much. And it is almost not fair calling it a daemon either, since the daemon only exist as long as there are visible notifications. It will also ofc make startup a little bit slower when the daemon and socket doesn't exist (meaning most of the time). imho, that will never be a problem for any usecase of a notification program.

And i also envision this:

herbe -x 10 -y 10 "msg1"
herbe -x 100 -y 500 "msg2"

Above code would result in two independent notifications displayed at the same time, but managed by the same process (the daemon). More options like --font and --color could ofc also be used.

But sometimes one might want to queue a notification (having the same behaviour as herbe currently have), and i don't think it would be a big deal adding a --queue option.

---

I have tried some of this out in my own messy not public fork, and i don't think any external libs are needed, and when it is clean it will not be that noisy (both linecount and complexity). But as you can imagine, this change will not really work as a "patch"...

[dudik]

I'm sorry, but I'm not really sure what problem you are facing.

If you want herbe to be non-blocking, append & to the end of the command, like this: herbe "Hello world" &

You also seem to want to remove the "waiting in queue" feature. That would be easy, I can write a patch for that, but I'm still not completely sure why would you want it. I know you want to display multiple notifications simultaneously, but how would you calculate the positions so they don't overlap?

[budRich]

You are probably right, and as i said, i haven't tested it.

And regarding multiple notifications at the same time (with different properties). That's one reason having a "background" daemon that will keep track of those things. But personally i would actually like the notifications to overlap, (the last notification will have the highest z coordinate), if their coordinates cross. Making sure they don't overlap would be up to the user (using -x -y --replace options).

Reason for not wanting a queue is just that, the ability to have multiple notifications at the same time. And, personally, if i would want a "queue" like behavior instead use --replace ID to replace a certain notification at a specific location and handle the queue externally or maybe it could be possible to have both --replace ID and --queue which would replace ID when the timeout for that notification have ran out.

---

Real world example:
Imagine a normal notification thing, you get notifications in the upper right corner of the screen. Those notifications are often automatically created
(e.g. notify-send -> tiramisu -> herbe --anchor 3 -x 10 -y 25 --replace 123 --queue -t 5 "message")

I have set up a custom use for notifications with my filemanager, when i f.i. delete multiple files i get a notification displaying full path of all the files. That notification have a smaller font and is placed in relation to the top-left corner of the filemanager. It is also a type notification that you don't want to wait in a queue, (you want to see it immediatly), at the same time, the default notification thing (top-right corner of screen) should not be affected (if existing and visible) by the filemanager notification. I think this is kind of the example i give in my video.

I actually do this now, but it isn't perfect. The way I do it, is restarting dunst with a different layout when i want to display the filemanger notification, and as soon as that notification has "done its job" i reload the "default" dunst notification. This means that it will destroy any notifications in the default position, and automatic notifications would get placed in the "filemanager specific notification area"...

---

and i am certain that a slight redesign of herbe (pseudo-daemon-socket thing), would solve that type of problems..

[dudik]

So, I created the patch: #14
Is it what you wanted?