Allow customization of direction of a sequence notifications

[jwdevel]

I recently upgraded dunst, and found that some functionality with the old geometry = ... syntax seems to be gone.

Here's what I want:
I put my notifications in the bottom-right of the screen.
Further, I want each new notification to stack on top of the existing ones.
So, after 3 notifications, it should look like this:

notification 3
notification 2
notification 1

That way, if I click on a notification with my mouse, I can be 100% confident that I will get the one I want.
Currently, to the best of my knowledge, there is no way to get this behavior — though I did have it working in an older version of dunst.

Today, the 3 notifications above will appear like:

notification 1
notification 2
notification 3

With this scheme, if I try to click on a notification, and a new notification pops up at the wrong moment, I will accidentally click the wrong one (since they all get shifted).

---

I remember fighting against this in the older version, too, and wound up with the positioning I chose just because it was the only one that seemed to preserve the positions of existing notifications when adding new ones.

Now, I can get similar behavior by putting this in the top-right (rather than bottom-left), but it's a little annoying to change my habits (:

My suggestion: Perhaps have some "preserve_position" boolean config value, which will ensure that existing notifications do not get moved, as new ones are added. I could also imagine it being accomplished via some sort of "gravity" value or "flow direction" or other approach. But the boolean seems most direct.

[bynect]

The sort option is your friend :)

sort (values: [true/false/id/urgency_ascending/urgency_descending/update], default: true)
If set to true or urgency_descending, display notifications with higher urgency above the others. critical first, then normal, then low.

If set to false or id, sort notifications by id.

If set to urgency_ascending, notifications are sorted by urgency, low first, then normal, then critical.

If set to update, notifications are sorted by their update_time. So the most recent is always at the top. This means that if you set sort to update, and stack_duplicates to true, the duplicate will always be at the top.

When the notification window is at the bottom of the screen, this order is automatically reversed

[jwdevel]

Ah, thanks — my dunst (1.9.0) only has true/false for that option. I guess I will need to wait for a newer one to percolate through Debian packages.

[jwdevel]

Re-opening this, since I built latest dunst (v1.12.1) and, as I understand it, I still cannot achieve what I want.

If I use origin = bottom-right, I cannot have the oldest item at the bottom. I tried sort=id, sort=true, sort=false. Thus, I cannot avoid the "accidentally click on the wrong item" problem described originally.

As far as I can tell, the documentation is wrong, in this respect?
It says "When the notification window is at the bottom of the screen, this order is automatically reversed".

But, as described before, with origin=top-right, I have:

notification 1
notification 2
notification 3

and with origin=bottom-right, it is the same (where I actually do want it reversed).

Or am I misunderstanding something, here?

[jwdevel]

Looking at the source it seems like maybe the "automatically reversed" behavior only applies to SORT_TYPE_UPDATE. Might be good to make that clearer in the docs, as an aside.

[jwdevel]

In fact, applying this small diff (which in my mind makes it do what the docs say) does make it do what I want.

diff --git a/src/notification.c b/src/notification.c
index a504ba2..c2d2363 100644
--- a/src/notification.c
+++ b/src/notification.c
@@ -204,7 +204,7 @@ int notification_cmp(const struct notification *a, const struct notification *b)
 {
         const struct notification *a_order;
         const struct notification *b_order;
-        if(settings.sort == SORT_TYPE_UPDATE && settings.origin & ZWLR_LAYER_SURFACE_V1_ANCHOR_BOTTOM){
+        if(settings.origin & ZWLR_LAYER_SURFACE_V1_ANCHOR_BOTTOM){
                 a_order = b;
                 b_order = a;
         } else {

Though of course, that changes behavior for existing users. So maybe it would be better to have some "id-reversed" sort order?

[jwdevel]

After using this a bit more, I realize that the 'close' action now closes the newest item rather than the expected oldest, since the order of the queue is reversed.

I made another patch locally to account for that, but I wonder if it needs a more full solution, where the display order of notifications is kept separate from the chronological order, or the "which should be closed next by default" order. Not sure what the overall best approach is, though I'm happy to provide my patch that makes it work reasonably well for me.

Generally, there's a bit of a confused presentation of these issues in the dunst docs; for instance dunstctl close says "Close the topmost notification..." but what is "topmost" if the anchor is different, and the display order is thus reversed? Is this a logical "top" or a physical as-it-appears-onscreen "top"? I think what most people want for a default close operation is "the oldest" without regard to top/bottom placement issues.

[bynect]

thanks for pointing this out. the close action closes the notification at the top of the queue and I would prefer to keep compatibility. maybe we can add a dunstctl close --oldest flag? also you can specify the id of the notification you want to close.

[jwdevel]

you can specify the id of the notification you want to close.

Yes, I saw that, but I could not find a way to get a list of all the IDs of displayed notifications. Is there a way to do that? I saw dunstctl history, which includes IDs in the JSON, but that is for old items, not currently-displayed ones.

In other words, if I wanted to write a script to close the lowest ID, how would I find what that is?

[bynect]

Ops you arw right. We have #1348 still pending