psuedodaemon brainstorm about herbe HOT 3 CLOSED

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?

from herbe.

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..

from herbe.

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

from herbe.