Nikos Tsipinakis

@stefanhusmann Between 1.3 and 1.4 we changed to dynamically calculate DPI instead of assuming it's 96. Does running ``` echo "Xft.dpi: 96" | xrdb - merge ``` And restarting dunst...

A bit of feedback about that patch, the close reason is defined in the [notification spec](https://developer.gnome.org/notification-spec/#signals). The value 4 is defined as `undefined/reserved reasons` while in this case it should...

If `notification_closed` is called with a reason of 2 then it's fine for a simple personal hack to get this to work but this wouldn't be how I'd implement it...

Reproduced, however reversing the order of the fonts so the emoji font is first seems to fix it, weirdly. Edit: Can you confirm that as well?

My theory: This is the result of pango (our font library) not properly failing when wrong font description syntax is used. The documentation of the format of the `font` parameter...

> Problem is in Pango or Cairo, most likely it's just Pango. Indeed the problem here is all pango - dunst doesn't do any of the text/font handling it just...

Other than the compositor issue the pause/unpause solution mentioned above is my workaround, and it works perfectly in my case. For why it doesn't work here, I suspect this is...

> I'm not sure what's causing it and I found no useful information online. This is likely not related to dunst, but I hope to start a conversation around this...

the `*Length` properties are not marked to emit a changed status signal, so the behaviour is correct here. I'm curious, what's the usecase to want to monitor these fields constantly?

This is an interesting idea, however there is the issue of identifying the source of the notification. If the source is a browser-based app then dunst will only see Firefox/Chrome...