Duplication of notifications is computed before scripts are applied

[resolritter]

Issue description

Problem: Duplication of notifications is computed before scripts are applied. Consider the following dunstrc:

[global]
  stack_duplicates = true

[hello]
  body = "Hello*"
  format = "Hello"

When two notifications are sent:

notify-send Hello "Hello foo" notify-send Hello "Hello bar"

They'll both be displayed the same way because of the [hello] script, but are not considered duplicates.

Solution: implement an option for computing duplicates after scripts are applied.

Side question: is there some API to dump all currently-visible notifications? Using xprop on notification windows does not provide enough information such as body and summary.

> xprop
_NET_WM_WINDOW_OPACITY(CARDINAL) = 4294967200
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_UTILITY
WM_CLASS(STRING) = "Dunst", "Dunst"
_NET_WM_NAME(UTF8_STRING) = "Dunst"
WM_NAME(STRING) = "Dunst"

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.7.3
• Install type: Compiled from source
• Window manager / Desktop environment: i3

Minimal dunstrc was provided above.

[fwsmit]

Is there a particular situation in which this is important to you? It seems pretty specific.

Side question: is there some API to dump all currently-visible notifications? Using xprop on notification windows does not provide enough information such as body and summary.

No I don't think so. There's dunstctl history for showing information about notifications in your history, though. I think a similar thing for open notifications shouldn't be too hard to add. There's also dunstctl count [displayed|history|waiting] for counting open/closed/paused notifications.

[resolritter]

Is there a particular situation in which this is important to you? It seems pretty specific.

Yes. One use-case is for chat platforms which include potentially-sensitive details in their notifications and I can't turn that off through settings, thus I use a script for omitting some parts of those notifications through format = (similar to what was demonstrated in the "Hello" example). Concretely:

[global]
  stack_duplicates = true

[format_chat]
  desktop_entry = "chat"
  # Only include the summary (the message's author), not the body (the message's content)
  format = "<b>%s</b>\nChat"

If I receive two different messages from Bob, each will produce its own separate notification because their bodies are different. In my format rule, however, I'm not using the notification's body, thus both will be displayed identically. That's when it gets confusing: I have stack_duplicates enabled, so if two notifications are displayed the same way, I expect them to be grouped into one. A new compute_duplicates_after_script option could be added for this use-case as to not breaking the existing behavior.

I think a similar thing for open notifications shouldn't be too hard to add.

This could also work for my use-cases, but it seems like the duplicate detection would work more robustly if processed directly in dunst's back-end.

[fwsmit]

Okay, makes sense. I wonder if we can just make this the default behaviour or if people are relying on the current behaviour.

This could also work for my use-cases, but it seems like the duplicate detection would work more robustly if processed directly in dunst's back-end.

Yeah, it's better to do it in dunst.