Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Changing urgency by a rule does not affect color of message #484
Use the default config and append the following rule:
The message is shown but with a blue color (like a normal message) instead of the red color for critical messages.
So the urgency is applied, but the colors are not changed accordingly.
This used to work with correctly with version 1.2. The commit which breaks this behavior seems to be 4bfae81.
Oh, err. Something went south in #428. Thanks for pointing this out.
Thank you! You're awesome! More people should know how to
When looking at the commit, I see I've flipped the rule application and the default color assignment. This is not so nice. But I'm reluctant to fix it in favor of #328. We want to drop these
Could you please use a workaround?
@tsipinakis I'd label this as
As I mentioned in #328 initially I only intend to change the handling of the sections internally to be technically rules but also work in the same way in the config file, we can talk about deprecation later.
Until then, this is definitely worth fixing but it'll probably have to wait a bit since this is a tough problem to solve and will probably required a rework of the rule system.
A quick outline of the problem: Dunst currently parses rules in the order they are defined and doesn't "go back" to check something if an attribute is updated so what happens internally is this
What's missing is a step between 3-4 where it goes back and applies all attributes for critical urgency. It's simple to implement now when the
I think I'm beginning to realise why the
PS: We really need more tests, this is a prime example of an issue that could've been caught by a proper test suite
I see your problem. Personally, I am in favor of threating the
For the moment, the proposed workaround (using another rule to apply the colors again) works for me.