Consistent Naming Scheme

[P9EA5Y]

Description

At current stage, Hyprland's configuration files are quite confusing and contains redundant wording, we should implement a more consistent naming scheme, and potentially rename some existing variables, some examples follow:

• no_border_on_floating, no_cursor_warps, and no_focus_fallback should be renamed to border_on_floating, cursor_wraps, and focus_fallback, with their respective boolean values reversed.
• tap-to-click and tap-to-drag, should have their hyphens replaced with underscores, or alternatively, with base word alternatives.
• enabled should be renamed to enable, without the past tense.

Additionally, more variables should have subcategories dedicated to them, for instance kb_*:

keyboard {
    model = 
    layout = 
    variant = 
    options = 
    rules =
    file =
}

[fufexan]

I agree with this. There are several sections where we can use more groups, as you say. input should have a section for mouse, keyboard, tablet, not only touchpad. device groups should probably also be set in there.

@spikespaz you also wanted to chime in on an issue like this.

[Root-Core]

The binding to toggle groups is togglegroup. The binding to toggle the pinned status is pin,

---

no_direct_scanout -> direct_scanout

I'm not sure about the disable prefix: disable_hyprland_logo -> enable_hyprland_logo disable_splash_rendering -> enable_splash_rendering disable_keybind_grabbing -> enable_keybind_grabbing disable_scale_checks -> enable_scale_checks

Could be replaces with a section for logs: disable_logs -> enable_logs or log or enabled in the section disable_time -> enable_time or log_time

disable_autoreload -> enable_autoreload or config_autoreload or autoreload in a new section config

disable_while_typing on the other hand is better, but enable_while_typing is pretty okay too.

---

enabled should be renamed to enable, without the past tense.

I prefer enabled, but this might be a habit at this point - as it feels like every framework has this nomenclature. "This is section enabled", not "section.enable()". "Enable" is something I do actively.. English is not my native tongue though, so I might be wrong. Just some bike-shedding.

[P9EA5Y]

I'm not sure about the disable prefix: disable_hyprland_logo -> enable_hyprland_logo disable_splash_rendering -> enable_splash_rendering disable_keybind_grabbing -> enable_keybind_grabbing disable_scale_checks -> enable_scale_checks

I feel prefixes such as disable and enable are redundant, it would be more understandable to just have:

• hyprland_logo
• splash_rendering/splash_render
• keybind_grabbing/keybind_grab
• scale_checks

In context to Hyprland's bool datatype: yes to hyprland_logo, no to splash_rendering.

disable_while_typing on the other hand is better, but enable_while_typing is pretty okay too.

As for disable_while_typing, potentially use while_typing, in context to Hyprland's on and off bool values? It might become confusing without the context tho.

I prefer enabled, but this might be a habit at this point - as it feels like every framework has this nomenclature. "This is section enabled", not "section.enable()". "Enable" is something I do actively.. English is not my native tongue though, so I might be wrong. Just some bike-shedding.

I tends to keep attributes in present tense when possible, because something being enabled is the consequence of modifying the configuration file, without an action, there wouldn't be consequences.

[spikespaz]

I have so many thoughts about this, let me think of how to begin.

I agree with some of the proposals above, and while I could come up with my own suggested renames (with accompanying reasoning), I will choose refrain for now. I think there's a more pertinent topic to discuss.

My flake, which sees very little usage (so far as I am aware at least), already aggressively renames socket events where they are exposed to Nix configurations. Several options for the config are also renamed, however these are not aggressive changes because I wanted it to mostly match the Hyprland documentation. You can see a relevant file here. The keen-eyed among you may notice that this mechanism also introduces a config group for gestures.workspace_swipe. Also, through this Nix mechana, the original name for any given configuration option may still be used and reproduced in the Hyprland configuration verbatim, enabling backwards-compatibility.

Hyprland (and to the extent of accusing Vaxry) has always been "inconsistent" in more facets than just the naming of configuration options. Take, for example, the binary name: "Hyprland"; can you think of another program on your system which has a binary starting with a capital letter? Another example, the original color format 0xAARRGGBB. Lastly, the names of socket events, which use different tenses and noun/verb order.

Unless we can somehow come up with a foolproof rulebook of naming schemes to throw at Vaxry, this issue is a fool's errand. It isn't as if we can expect him to consult the community to vote on names for configuration options, much less make a massive breaking change before 1.0.

Now, with all of that said, I think we should draft a document for 1.0 release, and keep it updated so that the config options can be re-named then.

[zakk4223]

One I constantly get caught by: general:gaps_in, general:gaps_out workspace rule -> gapsin, gapsout AND the syntax is different. general:gaps_in is comma delimited, workspace rule is space delimited.

I get WHY the workspace rule has to be space delimited, but the inconsistency is confusing

[Root-Core]

I feel prefixes such as disable and enable are redundant, it would be more understandable to just have:

You are right.

As for disable_while_typing, potentially use while_typing, in context to Hyprland's on and off bool values? It might become confusing without the context tho.

It is. While typing do what? Sure, on / off would do the trick. The on / off could be used for most values in the default config, in this context it would make sense.

I tends to keep attributes in present tense when possible, because something being enabled is the consequence of modifying the configuration file, without an action, there wouldn't be consequences.

Would you use activate instead of active? Let's agree to disagree, but I appreciate your opinion.

---

https://github.com/hyprwm/hyprlang/issues/13

I want to link to this issue in hyprlang, as this could be done in one step. Changing the default config path to another extension is also breaking and it would help to communicate the breaking changes in the naming scheme.

Now, with all of that said, I think we should draft a document for 1.0 release, and keep it updated so that the config options can be re-named then.

https://github.com/hyprwm/hyprlang/issues/13#issuecomment-1878867922

No such thing as a 1.0 - for now, I would guess. ;)

[P9EA5Y]

It is. While typing do what? Sure, on / off would do the trick. The on / off could be used for most values in the default config, in this context it would make sense.

In context to, on while_typing and off while_typing.

Would you use activate instead of active? Let's agree to disagree, but I appreciate your opinion.

Depends, as I have previously mentioned, I tend to focus on the action rather than consequence, changing the attribute enable would enable a specific feature. As for activate and active, it's up for a debate.

Changing the default config path to another extension is also breaking and it would help to communicate the breaking changes in the naming scheme.

I agree with this, we need some ways to convey the breaking changes, however legacy compatibility shall still remain, for instance, prefer the new config file when both exist, and fallback to the previous revision if it doesn't. And potentially a conversion tool?

Unless we can somehow come up with a foolproof rulebook of naming schemes to throw at Vaxry, this issue is a fool's errand. It isn't as if we can expect him to consult the community to vote on names for configuration options, much less make a massive breaking change before 1.0.

We do, indeed, desperately need a convention. I suggest temporarily halting on suggesting specific changes, and focus on establishing a consistent rulebook first.

[Root-Core]

Let's continue our discussion in #5719, where I've summarized the discussion we had so far.