Duplicate notifications from kdeconnect not merged

[infokiller]

I'm using kdeconnect to get notifications from my phone to my desktop. For some reason, only the notifications for calls are no deduped by dunst. Some debugging data:

• Output of dunst -p
• Output of dbus-monitor path=/org/freedesktop/Notifications- note that I removed the image data which is very big.

When I'm removing the image data (by removing it from the calling contact), deduping works.
Is deduping not applied when there is image data?

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.3.2 (2018-05-06)
• Install type: Official Arch Linux package
• Distro and version: Arch Linux

[infokiller]

OK, looking at the code I see that notifications with raw icons are never considered duplicates: https://github.com/dunst-project/dunst/blob/master/src/notification.c#L180

I'll look into adding a configuration option to disable this behavior.

[bebehei]

I'll look into adding a configuration option to disable this behavior.

No, we won't merge a new option for this. There are a few other ways possible to achieve this:

• Either assign a stack_tag to your notification (this got merged just recently, install dunst-git from AUR for this).
• Or - if you want to have an implementation feature - implement a comparison, which compares two raw images. Implementation wise, this may be hard. I won't write the code, but I'd merge such a feature. (Don't know what's @tsipinakis opinion on this).

[infokiller]

Thanks for the quick response!
Unfortunately I don't control these notifications, so I can't add a stack_tag directly. Is there something I'm missing?

Re implementing image comparison- is it not just a raw byte-to-byte comparison?
Another option would be to consider the raw icons equal only if the're the same size and have N same bytes (to avoid a full comparison where the images can be large).

[bebehei]

Unfortunately I don't control these notifications, so I can't add a stack_tag directly. Is there something I'm missing?

You've got rules. One of the key features of dunst. 😁

[rule kdeconnect_stack]
appname = kdeconnect
body = 'Incoming call from Contact'
set_stack_tag = kdeconnect_incoming

And automatically all notifications from kdeconnect with the specified body will get merged together.

That's just a small mockup. rules can do much more. But install dunst-git first, change the config and restart dunst then (killall dunst and then send a notification, it'll get started automatically).

Another option would be to consider the raw icons equal only if the're the same size and have N same bytes (to avoid a full comparison where the images can be large).

I don't think this would suffice. Most apps scale raw images to a fixed size before sending them over to dunst.

[infokiller]

Thanks a lot!
I don't think the rule you suggested is sufficient, because the notification body will be different for each caller- 'Incoming call from X' where X is the contact name. I could use body = Incoming call from *, but then if I get consecutive notifications from different callers they will be incorrectly considered as duplicates, right?

I don't think this would suffice. Most apps scale raw images to a fixed size before sending them over to dunst.
Hmm, yeah I thought the image sizes may be over simplified. Do you think that comparing a few pixels as a quick heuristic will be reasonable?

[tsipinakis]

I could use body = Incoming call from *, but then if I get consecutive notifications from different callers they will be incorrectly considered as duplicates, right?

That's correct, that should work just fine.

Implementation wise, this may be hard. I won't write the code, but I'd merge such a feature. (Don't know what's @tsipinakis opinion on this).

I'd definitely want to see this implemented. Pure speculation without looking at all into possible implementations, a simple memcmp could work, or maybe hash the data to avoid comparing the entire thing every time.

[progandy]

or maybe hash the data to avoid comparing the entire thing every time.

glib2 provides g_compute_checksum_for_data, so no need to add another dependency or reimplement it. MD5 is probably good enough and faster than the other possible algorithms.

[bebehei]

I'd go with @progandy's solution. If I recall it correctly: There's just a little problem you might have to work out: Not the whole bytestring might be initialised. So a plain hash over the whole image bytes might not work out, because there might be uninitialised memory.

[infokiller]

@tsipinakis IIUC body = Incoming call from * (along with set_stack_tag) is problematic because it will cause notifications from different callers to be merged, right?

@tsipinakis @progandy
How will hashing the image data help here?
I mean, computing the hashes will still require to read all the data of both images (though you will only have one comparison). Am I missing something?

[bebehei]

Yeah, but notifications aren't just compared once. On every notification, the whole waiting queue and displayed notifications will get compared to the incoming notification. And not hashing the data would require to read the data over and over again.

[infokiller]

Got it, thanks!

[bebehei]

I'm working currently on the comparison. It's actually pretty straight forward with g_compute_checksum_for_data.

If you know how to build dunst, you can have a look at master...bebehei:checksummed-icons. It works but it needs heavy polishing and I have to split the commits.

[bebehei]

@infokiller Fix is on the way (#586). I'd appreciate it if you could test it.