Deprecating/removing per-urgency command line flags

[tsipinakis]

One of the changes I have been looking into in the long term is integrating urgency with rules. In the simplest form, having the urgency_{low,normal,critical} sections imply a match on their respective urgencies without having a separate concept of urgency within the code.

We currently have command line flags that allow the customization the attributes that can be set in an urgency section: -lb,nb,cb, -lf/nf/cf/, -lto/nto/cto, -li/ni/ci and -lfr/nfr/cfr for the background, foreground, timeout, icon and frame colour of low, normal and critical notifications respectively.

But by implementing the change mentioned above this means that 1) everything that can be set via rules can now also be set in urgency sections, so this list becomes incomplete and that 2) re-implementing these flags with the rule system adds unnecessary noise to the code.

My opinion is that these flags are redundant and overly specific since by the point that these flags are needed to be used it is probably simpler to create a second config file and use that via the -config flag.

Is anyone relying on these flags for anything? If so what's the use case?

[nhatzHK]

Coming from #357 these flags are sed to load current configurations, like the current colors. This helps blending the notification with the current colourscheme for example. Will there be an alternative way to do this when those flags get removed?

[bebehei]

@nhatzHK The configuration will be done via rules. Rules are far more powerful than these per urgency flags. Only "downside" is, that these rules cannot get set via command line.

[tsipinakis]

Only "downside" is, that these rules cannot get set via command line.

Which we can consider to implement down the road if we can come up with an acceptable interface for it.

[nhatzHK]

I'd like to propose shell commands invokation in config files as an alternative, as I did there.

I would propose to make commands usable in the config file. For example, I could have the following:

frame_color = `xrdb -query all | grep *colorN | awk '{print $x}'`
# or
frame_color = $(same as above)

[bebehei]

@tsipinakis If we want to deprecate the urgency settings and make the users aware to translate these configuration blocks into rules, we should actually start warning the users now. No matter if we remove it in the next release or somewhat later.

[tsipinakis]

If we want to deprecate the urgency settings and make the users aware to translate these configuration blocks into rules

I think you misunderstood the intent of this issue, the urgency-specific command line flags will be removed but the urgency sections will remain.

I am talking about an internal refactoring of how we handle urgency i.e. instead of specifically loading the urgency sections on their own instead parse them as rules and add an implicit urgency = {low,normal,critical} while parsing. (That's for backwards-compat, we'll see about removing these later though I doubt it's worth the effort).

[bebehei]

Well, this makes no sense to me. Either we should drop them (and translate the previous urgency_* categories to rules for backwards compatibility) or we should let them stay fully in their previous intention.

It makes no sense to me, translating these categories separately to rules and processing it like rules, but declaring it like a setting.

Rules are easy to understand, as these are processed in sequence, so anyone can understand how these are applied. When you go on and translate these to rules by default (not just for backwards comp), you won't be able to change the sequence.

Also the main point: Why do you want to remove the command line flags, but not the ini categories? In terms of consistency, I don't understand this.

[chrishoage]

I found this GHI though the hosted documentation. I wanted to provide my input.

I rely on the command line flags so that I can set colors via pywall with out having to have the entire dunstrc file as a pywal template.

In my xprofile I start a wrapper script that sources the pywal colors and supplies the current colors as command line argument to dunst.

This allows me to keep my dunstrc file with all my other dotfiles, while having colors come from a single place.

If there are no command line replacements when the existing ones are depreciated then please consider allowing an include (or similar) statement that allows users like myself to source only the colors from something like $HOME/.cache/wal/dunstcolors

[fwsmit]

I found this GHI though the hosted documentation. I wanted to provide my input.

I rely on the command line flags so that I can set colors via pywall with out having to have the entire dunstrc file as a pywal template.

What's wrong with that? I believe they ship their own dunst template.

In my xprofile I start a wrapper script that sources the pywal colors and supplies the current colors as command line argument to dunst.

This allows me to keep my dunstrc file with all my other dotfiles, while having colors come from a single place.

Your dunst template will be in ~/.config/wal/templates/, so that's with your other configs.

If there are no command line replacements when the existing ones are depreciated then please consider allowing an include (or similar) statement that allows users like myself to source only the colors from something like $HOME/.cache/wal/dunstcolors

If that works for you that's fine too. I recently suggested this feature, #796 . I will probably implement this before the command line options get deprecated. Take a look at that and let me know if this would fix your issue

[chrishoage]

What's wrong with that? I believe they ship their own dunst template.

They do not ship their own template. Until recently I used this approach.

Your dunst template will be in ~/.config/wal/templates/, so that's with your other configs.

While that is technically correct, if one uses symlinks to place config files in $XDG_CONFIG_HOME / $HOME/.config from where one keeps their dotfiles (say a dotfiles directory that is tracked in git) then any changes one makes to the files are reflected in the original location. If one is to make changes to a templated config then you have to have copy the changes you made back to the original template, or otherwise generate the template after every change. This can be cumbersome. With the commit I linked to my dotfiles repo I can make changes to the dunstrc file and have the changes immediately tracked in git, and have pywal have control over the colors though the CLI.

Take a look at that and let me know if this would fix your issue

Presuming that the include directive could expand ~ then it would be perfect and satisfy my desire to have the bulk of the config as a symlink to $XDG_CONFIG_HOME / $HOME/.config while allowing colors to be templated from a tool like pywal. For example include ~/.cache/wal/dunst

Thank you for your time in discussing this issue with me 🙂

[fwsmit]

While that is technically correct, if one uses symlinks to place config files in $XDG_CONFIG_HOME / $HOME/.config from where one keeps their dotfiles (say a dotfiles directory that is tracked in git) then any changes one makes to the files are reflected in the original location. If one is to make changes to a templated config then you have to have copy the changes you made back to the original template, or otherwise generate the template after every change. This can be cumbersome. With the commit I linked to my dotfiles repo I can make changes to the dunstrc file and have the changes immediately tracked in git, and have pywal have control over the colors though the CLI.

Understandable. You could still do it like this: keep your template in ~/.config/wal/templates/dunstrc. Then link the template to ~/.config/dunst/dunstrc.template. Then you can start dunst with dunst -conf ~/.cache/wal/dunstrc. This way your dunstrc template is still in the right directory and dunst uses the non-template version.

Presuming that the include directive could expand ~ then it would be perfect and satisfy my desire to have the bulk of the config as a symlink to $XDG_CONFIG_HOME / $HOME/.config while allowing colors to be templated from a tool like pywal. For example include ~/.cache/wal/dunst

Yeah, the include directive would probably implement it with wordexp (see wordexp(3)). This expands it like a shell would do it. Envirorment variables, ~, and regex would work as expected.

[chrishoage]

Yeah, the include directive would probably implement it with wordexp (see wordexp(3)). This expands it like a shell would do it. Envirorment variables, ~, and regex would work as expected.

Fantastic! I've subscribed to #796 so I know when this work is completed. Thank you!

[fwsmit]

Closing, as these commands are now deprecated. Support for drop-in config files is being worked on in #997.