[meta] Aesthetics & customization

[bynect]

For the great joy of the ricing community I want to add some options to customize the look and feel of dunst. So this is a summary for the customization related issue & prs

Done

• Fix progress bar weird behavior at small percentages (#1227 merged)

• Custom corners (#1268 merged)

• Wayland cursor update #1276

• Dynamic height & alignment (#1342)

• Color gradients (#1273, #1286 for the progress bar gradient)

  • Potentially add gradient to other colors (foreground, background, etc)
  • Maybe add the ability to choose a custom angle or anchor points

• Settings reload (#968 -> #1350)

• Cache icon content by path and timestamp (#1061) --> #1473

WIP

• Possible problems with fractional scaling that result in pixel inaccuracies

  • Possible solution #1337

• Fix icon size handling (#1086 and #1075)

TODO

• Add custom color choice for progress bar background

• Allow the use of special color values like foreground,background

• X11 refactor #477

• Themes! Some ideas on the comments below

• Percentages as units (#991)

  • Note: easy to implement but multiple monitors should be taken into account

• Rework borders and frames (#1136 and) so that they can

  • be of different colors ( #673)
  • only specific borders can be drawn (#1136 and #733)
  • double corners (#738)

• Custom action and action count format (#1218 and #509)

• Allow a custom color or stylesheet for svg/symbolic icons ( #1076 and #994 -- #1081)

• Inconsistency between wayland and x11

• Fix rectangle artifacts (probably generated during rendering with xlib) (#1031 #1057)

Future ideas

• Shadows (#926)

• Gif support (#773)

• There are some possible improvements to the layout to move some things around (#741)

• Buttons for actions (#234)

• Notification specific geometry or show on multiple windows (#45, #265). This will require support for multiple windows #1018

Known problems

• Flickering during redraws ( #1240, #1159 and others)
• Multiple fonts not working, this is a limitation of pango but maybe something can be done (#1211)
• Issues with borders (#1188 and #1241)
  • This could be solved by reworking borders/frames altogether

Obviously if you have any idea feel free to write here or open an issue with feature request

[bynect]

@fwsmit if you have anything to add feel free or let me know. Could you please add the proper tags to this issue?

[fwsmit]

I have a few ideas for improving the theming of Dunst. The default theme of Dunst could be improved (probably some default settings as well). Another thing is to add a theme keyword that allows you to switch theme with one line. Dunst could ship some default themes

[bynect]

I have a few ideas for improving the theming of Dunst. The default theme of Dunst could be improved (probably some default settings as well). Another thing is to add a theme keyword that allows you to switch theme with one line. Dunst could ship some default themes

Nice👍

I was thinking that when we add multiple windows, different windows/screens could have different themes (so a theme can be chosen by a rule or something like that)

For the default themes I like the idea, we could add things like gruvbox out of the box

[bynect]

I was thinking of adding a theme section which contains all the theme related things for every theme.

[theme]
name = whatever
background =
foreground =
corners =
corner_radius =
frame =

And then you can use a set_theme to use the theme. And using rules you can still override the theme

[fwsmit]

I was thinking about making a themes directory, like ~/.config/dunst/themes and /etc/dunst/themes. Each file in the directory could just use the standard config format, maybe excluding some keywords that don't relate to theming. It would work similar to the proposal of the include keyword, #796, but more focused. It might sound like it's more limited, and that's true, but it would be way easier to use. That is also worth a lot.

[bynect]

I was thinking about making a themes directory, like ~/.config/dunst/themes and /etc/dunst/themes. Each file in the directory could just use the standard config format, maybe excluding some keywords that don't relate to theming. It would work similar to the proposal of the include keyword, #796, but more focused. It might sound like it's more limited, and that's true, but it would be way easier to use. That is also worth a lot.

Well, maybe we can do a combination of the approach? Basically theming is done in a special section of the ini file. And we can split the theme in other config files (like the dunstrc.d). So basically if a user wants to use the theme in the main file he can, otherwise he can create another config file specific to themes. And the syntax is still ini to be consistent.

Also, I remembered that in ini the section name should be unique, so maybe we can add subsections for theming. like

[theme.gruvbox]
//...

[theme.mocha]
...

[theme.atom-dark]
...

[bynect]

I have one big perplexity though: should themes be associated with a single notification or with a window? (given that multiple window support will be implemented sooner or later)

Because having a theme for every single notification is quite strange for me personally, especially if different notification have themes that are not "compatible" with each other (think: different corners, frames, spacing).

So I would say that a theme should be associated with a window and in general be the original source of all the colors and layout, which can then be overridden by the rules. (it would be also interesting to match rules based on theme)

edit: It just occurred to me that every theme should define different values for each urgency level. Or alternatively we can do something like

[theme AtomDark]

[.low_urgency]
color =
corners = 
etc.

[.critical_urgency]
...

or this

[theme Gruvbox]

low_urgency.color =
low_urgency.background =
low_urgency.corners =

critical_urgency.color =

//... using _ is also fine

normal_background = #fff

the above idea are meant to replace low/normal/critical_urgency sections.

another possibility is creating multiple low/normal/critical_urgency and matching them against themes. so they are more similar to rules. Every theme then defines the appropriate sections.

But either way, I am sure that each theme has to be linked directly to the low/normal/critical_urgency settings. We have to somehow decide what's the best way to handle this

[bynect]

@fwsmit if you could please merge #1268 and review #1286 I will start implementing the theming. The main idea of how theming should work in the comment up, if you think I missed anything please tell me.

Also, I don't know if we should ask other users if they like the idea?

[fwsmit]

I have one big perplexity though: should themes be associated with a single notification or with a window? (given that multiple window support will be implemented sooner or later)

Most theming in dunst can be done per notitifcation using rules, so it might make sense to allow the theme to also be set via a rule. It depends on how a theme defines theming rules.

Because having a theme for every single notification is quite strange for me personally, especially if different notification have themes that are not "compatible" with each other (think: different corners, frames, spacing).

So I would say that a theme should be associated with a window and in general be the original source of all the colors and layout, which can then be overridden by the rules. (it would be also interesting to match rules based on theme)

edit: It just occurred to me that every theme should define different values for each urgency level. Or alternatively we can do something like

[theme AtomDark]

[.low_urgency]
color =
corners = 
etc.

[.critical_urgency]
...

The ini parser doesn't support nested sections I think. And I don't know if that's standard ini syntax.

or this

[theme Gruvbox]

low_urgency.color =
low_urgency.background =
low_urgency.corners =

critical_urgency.color =

//... using _ is also fine

normal_background = #fff

This one is not backward compatible. Another option is to only allow themes in a separate file. Then the name of the theme could be taken from the filename or something.

the above idea are meant to replace low/normal/critical_urgency sections.

another possibility is creating multiple low/normal/critical_urgency and matching them against themes. so they are more similar to rules. Every theme then defines the appropriate sections.

But either way, I am sure that each theme has to be linked directly to the low/normal/critical_urgency settings. We have to somehow decide what's the best way to handle this

Note that it should also be possible to easily change theme. For example from dark mode to light mode. Dunst could even integrate with the desktop api for dark/light theme so this happens automatically.

[bynect]

Most theming in dunst can be done per notitifcation using rules, so it might make sense to allow the theme to also be set via a rule. It depends on how a theme defines theming rules.

The idea was to allow rules to set themes. But the problem I see is that themes may define "general" options that don't change a single notification but the whole window. For example I was thinking of adding a window_frame (name temporary) that is basically an additional border for all notifications (see #738). This and other things (think about separator, which to choose between the top and bottom if they have different themes?) break if theme is notification specific. So I was thinking on making themes tied to a window (yes I am working on the multiple window 🤣).

The ini parser doesn't support nested sections I think. And I don't know if that's standard ini syntax.

It is an informal convention and should be added to the parser yes. Maybe something less breaking would be

[theme.atom]

normal_urgency_background =
# different from background and only available in theme sections

# or alternatively
color = (low_urgency_color,  normal_color2, critical_color3)

This one is not backward compatible. Another option is to only allow themes in a separate file. Then the name of the theme could be taken from the filename or something.

If possible I would avoid these for two reason:

1. makes themes different from the other configuration with the risk of creating another pseudo-language
2. A lot of people hate clutter files
3. They are potentially similars to the drop-ins in dunstrc.d

Note that it should also be possible to easily change theme. For example from dark mode to light mode. Dunst could even integrate with the desktop api for dark/light theme so this happens automatically.

this is surely a design goal. Maybe we can add a match_system_theme or something to the rules? (But I would add that to window rules and not notification rules for the reason added in the above comment).

All in all, maybe I should focus first on the multiple windows implementation before the theming (for less friction)

[bynect]

I was watching closely the layout and I noticed several pixel imperfections, which are either caused by cairo antialiasing or by precision error in the drawing code (possibly due to the dpi floating scaling).

The white arrow presents no line. The red arrow presents a grey line. The blue arrow presents a purplish (frame color) line.

I also highlighted in yellow that some lines "bleed" into the frame, in every notification but the first

[bynect]

I noticed several problem in the icon handling code, so I will start delving into that. On my system, the recursive lookup does never work. I think the find_in_theme is the culprit.

Edit: I rediscovered #1116 and #1094