Closed ilya-bobyr closed 2 years ago
Additionally, we probably now want to deprecate urgencyConfig
and dzenUrgencyHook
(or would that be too annoying for users? I don't know)
Additionally, we probably now want to deprecate
urgencyConfig
anddzenUrgencyHook
(or would that be too annoying for users? I don't know)
I do not have a strong opinion, though I also do not have a lot of Haskell experience %)
It does seem reasonable to deprecate urgencyConfig
in favor of the Default
instance.
Not sure why was Default
was not used in the first place. I assumed there might be a reason I was not aware of.
As for dzenUrgencyHook
- I do not think it should be deprecated.
There could be other urgency hook handlers. And borderUrgencyHook
and spawnUrgencyHook
are already defined.
Most code will probably be more readable if it is using dzenUrgencyHook
directly, instead of the def
instance.
In short, I could add deprecated to urgencyConfig
.
Having one way to do simple things is good :)
In short, I could add deprecated to
urgencyConfig
. Having one way to do simple things is good :)
This seems fine to me; let's do it!
In short, I could add deprecated to
urgencyConfig
. Having one way to do simple things is good :)This seems fine to me; let's do it!
Added :)
Thank you!
As the XMonad config is commonly customized by saying
It seems consistent to allow the same for an individual hook config:
Description
Include a description for your changes, including the motivation behind them.
Checklist
[x] I've read CONTRIBUTING.md
[x] I've considered how to best test these changes (property, unit, manually, ...) and concluded: this is configuration only change, if it compiles, it is good.
[x] I updated the
CHANGES.md
file