Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fullscreen as a global option #644

Closed
ivomac opened this issue Jul 30, 2019 · 7 comments · Fixed by #803
Closed

Add fullscreen as a global option #644

ivomac opened this issue Jul 30, 2019 · 7 comments · Fixed by #803
Labels

Comments

@ivomac
Copy link

ivomac commented Jul 30, 2019

Currently it is possible to change the fullscreen behaviour through rules, but there is no way to change the global behaviour. I am currently using this to use "pushback" for all notifications:

[low]
msg_urgency = low
fullscreen = pushback

[normal]
msg_urgency = medium
fullscreen = pushback

[critical]
msg_urgency = critical
fullscreen = pushback

it would be nicer to just have a single line in [global]:

[global]
fullscreen = pushback
@tsipinakis
Copy link
Member

tsipinakis commented Jul 30, 2019

That's a good idea, there should be a default value for these in the global section.

For now to make your workaround shorter you can use a single rule with no match clause:

[pushback_all]
fullscreen = pushback

Edit: Mind the interaction with other rules, they are applied sequentially so it should be the first one modifying fullscreen to avoid overriding another rule.

@ivomac
Copy link
Author

ivomac commented Jul 30, 2019 via email

@bebehei
Copy link
Member

bebehei commented Jul 30, 2019

That's a good idea, there should be a default value for these in the global section.

Please not. Having rules is the best thing we have. Having "global" configuration options just introduce more complexity while being less flexible. The rules cover every possible configuration case perfectly.

It's just not reallly documented that "order makes a difference".

@tsipinakis
Copy link
Member

Having "global" configuration options just introduce more complexity while being less flexible

Interesting that you see it this way. In my mind rules are all about overriding a certain attribute for a specific group, but sometimes like here one wants to change the default value of everything.

The goto would be a section at the top like this:

[defaults]
fullscreen = pushback
frame_color = "#..."

Given that a lot of these, frame_color, format etc already do this if placed in the global section, why not expand that to fullscreen?

@bebehei
Copy link
Member

bebehei commented Jul 31, 2019

I thought our work was previously directed towards rules. We wanted to improve rules and even want to deprecate such global settings (see #328). A rule without a matcher is effectively a global setting. But in code, it's less complex.

The only point, we have to communicate in the docs: Order makes a difference there.

@tsipinakis
Copy link
Member

We wanted to improve rules and even want to deprecate such global settings (see #328). A rule without a matcher is effectively a global setting. But in code, it's less complex.

Indeed but the issue you link is about the urgency_ sections, not about the global one. What you're suggesting is to split "global" settings like follow, geometry etc and per-notification ones into different sections, right? It does make a lot of sense to do that but currently we don't even have a "proper" issue to track this, no work has been done.

What I'm trying to say is that whatever the state we're trying to move towards, from the user perspective it's currently inconsistent. (why is frame_color supported in the global section but fullscreen is not?). IMO We should try to keep a consistent state in the config, even if we're planning to change the recommended format in the future.

The only point, we have to communicate in the docs: Order makes a difference there.

That's true this is indeed missing and should be documented.

@bebehei
Copy link
Member

bebehei commented Aug 1, 2019

from the user perspective it's currently inconsistent

Indeed.

(why is frame_color supported in the global section but fullscreen is not?)

Just because I didn't implement it in my PR. 😝

And I think the actual way to go, is simply deprecating frame_color inside the global section. In reality it's a per notification setting and not a global one.

Just see the following code. Do you know how it behaves? After about half a year abstinent, I still know, I've changed it, but I don't know my intention at all.

dunst/src/settings.c

Lines 627 to 631 in 6c4eeda

settings.colors_crit.frame = option_get_string(
"urgency_critical",
"frame_color", "-cfr", settings.frame_color ? settings.frame_color : defaults.colors_crit.frame,
"Frame color for notifications with critical urgency"
);

The only thing I'm sure about: We have to write it this way, because we have to respect the default and the global settings. Implementing the same with a rule would save 10 settings queries.

@fwsmit fwsmit mentioned this issue Mar 1, 2021
4 tasks
fwsmit added a commit to fwsmit/dunst that referenced this issue Mar 8, 2021
This commit tries to make the setttings more consistent by implementing
the settings as rules everywhere where it's possible. This means the
rule code from settings.c can be removed and everything is defined in
settings_data.h. Rules are now also allowed in the global and urgency
sections. This means dunst-project#644 is now fixed.

The special sections are implemented as rules by giving them implied
filters. The global sections has no filters and the urgency sections
only have filters of their respective urgency. To avoid confusion, no
other filters are allowed in these sections.

Fixes dunst-project#644
fwsmit added a commit to fwsmit/dunst that referenced this issue Mar 8, 2021
This commit tries to make the setttings more consistent by implementing
the settings as rules everywhere where it's possible. This means the
rule code from settings.c can be removed and everything is defined in
settings_data.h. Rules are now also allowed in the global and urgency
sections. This means dunst-project#644 is now fixed.

The special sections are implemented as rules by giving them implied
filters. The global sections has no filters and the urgency sections
only have filters of their respective urgency. To avoid confusion, no
other filters are allowed in these sections.

Fixes dunst-project#644
fwsmit added a commit to fwsmit/dunst that referenced this issue Mar 9, 2021
This commit tries to make the setttings more consistent by implementing
the settings as rules everywhere where it's possible. This means the
rule code from settings.c can be removed and everything is defined in
settings_data.h. Rules are now also allowed in the global and urgency
sections. This means dunst-project#644 is now fixed.

The special sections are implemented as rules by giving them implied
filters. The global sections has no filters and the urgency sections
only have filters of their respective urgency. To avoid confusion, no
other filters are allowed in these sections.

Fixes dunst-project#644
fwsmit added a commit to fwsmit/dunst that referenced this issue Jun 7, 2021
This commit tries to make the setttings more consistent by implementing
the settings as rules everywhere where it's possible. This means the
rule code from settings.c can be removed and everything is defined in
settings_data.h. Rules are now also allowed in the global and urgency
sections. This means dunst-project#644 is now fixed.

The special sections are implemented as rules by giving them implied
filters. The global sections has no filters and the urgency sections
only have filters of their respective urgency. To avoid confusion, no
other filters are allowed in these sections.

Fixes dunst-project#644
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants