[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 (Corners patch part 1 #1227 merged)
• Custom corners (Corners patch 2 #1268 merged)
• Wayland cursor update Wayland: suport GTK/CSS cursor names #1276
• Dynamic height & alignment (Implement dynamic height and change vertical padding #1342)

Mostly done or WIP

• Color gradients (Feature: Color gradient #1273, Gradients #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 (proof of concept: dunstctl reload #968 -> [RFC] config reload mechanism #1350)

• Possible problems with fractional scaling that result in pixel inaccuracies

  • Possible solution Refactor draw code to use cairo_surface_set_device_scale #1337

TODO

• X11 refactor Refactoring x11 #477

• Themes! Some ideas on the comments below

• Percentages as units (Geometry as a percent of screen width #991)

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

• Rework borders and frames (Allow setting individual border's properties #1136 and) so that they can

  • be of different colors ( frame_color issue #673)
  • only specific borders can be drawn (Allow setting individual border's properties #1136 and Customize individual frame edges #733)
  • double corners (Double Borders/frames? #738)

• Custom action and action count format (Proposal: Show action count in notifications #1218 and Custom indicators for URL and Actions #509)

• Fix icon size handling (Can't change icon size with enable_recursive_icon_lookup #1086 and Named SVG icons are scaled to max_icon_size #1075)

• Allow a custom color or stylesheet for svg/symbolic icons ( Allow customization of SVG fill color #1076 and Allow setting icon colors #994)

• Cache icon content by path and timestamp (dunst shows the same icon when the content of --icon is changed #1061)

• Fix rectangle artifacts (probably generated during rendering with xlib) (Notifications appear as large boxes #1031 A ghost rectangle is rendered for a split second before the actual notification balloon #1057)

Future ideas

• Shadows (Add support for shadows #926)

• Gif support (Gif Support #773)

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

• Buttons for actions (Clickable buttons for actions? #234)

• Notification specific geometry or show on multiple windows (Show Messages on All Monitors #45, Application name based Geometry #265). This will require support for multiple windows [meta] Support multiple windows. #1018

Known problems

• Flickering during redraws ( Flickering caused by age seconds #1240, Dunst notifications flicker after unpausing (X11 + compositor) #1159 and others)
• Multiple fonts not working, this is a limitation of pango but maybe something can be done (Multiple fonts not working together #1211)
• Issues with borders (Borders on some notifications with frame_width = 0 #1188 and Notification Content Area Width miscalculated when frame_width is greater than 0 #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