Dunst v1.12.0

[bynect]

There have been many important contributions in the last few months.
Some notable changes are: adding hot-reload for the configuration, exporting
rules via dunstctl, adding color gradients, removing default hard-coded icons.
For detailed information consult the changelog.

Important notice for all users:

The behaviour of the setting height has been changed in a breaking way.
Before you could specify a single value that would be used as the max height
of a notification. In this release the dynamic height was implemented to make
this settings behave more similarly to width.
Now the values accepted are either a single number (for a fixed height) or
a tuple of numbers (for a min/max range).

The way of specifying a maximum height before was:
height = 300

The equivalent way now is:
height = (0, 300)

Furthermore the preferred syntax for the offset settings has been changed
from NxN to (N,N). The old syntax is supported nevertheless.

If you are a maintainer it would be helpful to include the message above when
an user updates from an older version of dunst.

Take a look at the changelog for all the bug fixes and improvements.

Added

• Export rules via dbus with dunstctl rules [--json] (Export rules via dbus #1212)
• Added checks and messages for missing DBUS_SESSION_BUS_ADDRESS (Check DBUS_SESSION_BUS_ADDRESS and give more meaningful errors #1389)
• Add -e/--exit flag to dunstctl is-paused to exit with 1 when paused (feat: exit with 1 when paused for is-paused #1378)
• Add color gradients for the progress bar (by providing a list of colors instead of one) (Add color gradients #1370)
• Use TESTDIR env var as the base for the test program (Use TESTDIR env var #1376)
• Add dunstctl reload to hot reload the configuration ([RFC] config reload mechanism #1350)
• Add an optional id to dunstctl close (Add an optional id to dunstctl close #1351)
• Print compile-time options in dunst --version (Print compile-time options in dunst --version #1336)

Changed

• BREAKING: Implement dynamic height (changes the the height setting, see manual) (Implement dynamic height and change vertical padding #1342)
• Change the preferred syntax of offset from NxN to (N,N) (Refactor length parsing and make offset a length #1330)
• Install the systemd service file in the session.slice (Place dunst.service in session.slice #1397)
• Open url with dunstctl action if no action is present (dunstctl action is not working, but mouse click works #1345,Open url if no action is present #1395)
• Remove default icons (now no icons are hard-coded) (Remove default icons and refactor icon-lookup #1365,How to disable icons in dunstify #1358)
• Various updates to documentation and test suite

Fixed

• Order of context menu was reversed (Reverse order of context menu #1394,[Q] invoke dmenu revers order #1375)
• Resolve ~ and $HOME in icon_path (Resolve ~ and $HOME in icon_path #1383,Resolve ~ or $HOME in icon_path #1371)
• Fix broken link to freedesktop's notification specs in man page (Fix broken link to freedesktop's notification specs in man page #1381)
• Remove the message about shortcuts deprecation (Update config man page #1353)
• Fix vertical padding behaviour (Implement dynamic height and change vertical padding #1342)
• Fix bash completion (Fix bash completion #1347)
• Fix file suffix for fish completions during installation (Fix file suffix for fish completions during installation #1339)

Full Changelog: v1.11.0...v1.12.0

---

This discussion was created from the release Dunst v1.12.0.

[stapelberg]

Thanks for the new release.

Unfortunately, I noticed that dunst had a new release because my notifications suddenly were a lot larger than before (because of the changed height semantics).

While fixing my config file on this machine is easy, now my config file can no longer be shared between my work machine (older dunst) and private machine (newer dunst).

Please, in the future, can you no longer break existing configuration files? There is a lot of value in stability. Thank you for considering.

[bynect]

thanks for the feedback.
We didn't want to break things, but this was needed to fix the inconsistent behavior of height (compared to width)

[prezdev88]

Hi! I get it now. The only thing is that, in my case, I had no idea why my notifications were appearing so tall.

[bynect]

Hi! I get it now. The only thing is that, in my case, I had no idea why my notifications were appearing so tall.

Sorry it seems some more communication was needed. I did suggest to add a notice for maintainers but I guess they didn't

[stapelberg]

We didn't want to break things, but this was needed to fix the inconsistent behavior of height (compared to width)

To be clear, as a user, I don’t care at all about consistency. If the current height option is not ideal, introduce a new one and map the current one to the new option transparently. What I care much more about is how much effort your software causes me on an ongoing basis.

Sorry it seems some more communication was needed. I did suggest to add a notice for maintainers but I guess they didn't

No, IMHO more communication would not have made things better. My point is that any required change is a change too much, in particular when it’s only about aesthetics (as opposed to, say, fixing a critical security issue).

In the i3 tiling window manager project, we went to great lengths to keep old configuration files working. In fact, if you started using i3 with the very first released version, and then upgraded to a 10 year later version, your config file will transparently be migrated from the old format to the new format (in-memory, so that i3 can start and work).

Of course I’m not saying every project needs to take as strong a stance on backwards compatibility. But please, re-calibrate your sense of when breaking changes are truly called for.

[bynect]

We didn't want to break things, but this was needed to fix the inconsistent behavior of height (compared to width)

To be clear, as a user, I don’t care at all about consistency. If the current height option is not ideal, introduce a new one and map the current one to the new option transparently. What I care much more about is how much effort your software causes me on an ongoing basis.

Sorry it seems some more communication was needed. I did suggest to add a notice for maintainers but I guess they didn't

No, IMHO more communication would not have made things better. My point is that any required change is a change too much, in particular when it’s only about aesthetics (as opposed to, say, fixing a critical security issue).

In the i3 tiling window manager project, we went to great lengths to keep old configuration files working. In fact, if you started using i3 with the very first released version, and then upgraded to a 10 year later version, your config file will transparently be migrated from the old format to the new format (in-memory, so that i3 can start and work).

Of course I’m not saying every project needs to take as strong a stance on backwards compatibility. But please, re-calibrate your sense of when breaking changes are truly called for.

I don't usually go around breaking configuration for hobby.
But thanks for the feedback, I made this #1412.
As I wrote there I will probably need to release a 1.12.1 soon, so rest assured 👍🏻