Open P9EA5Y opened 4 months ago
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.
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.
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.
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.
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
I feel prefixes such as
disable
andenable
are redundant, it would be more understandable to just have:
You are right.
As for
disable_while_typing
, potentially usewhile_typing
, in context to Hyprland'son
andoff
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. ;)
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.
Let's continue our discussion in #5719, where I've summarized the discussion we had so far.
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
, andno_focus_fallback
should be renamed toborder_on_floating
,cursor_wraps
, andfocus_fallback
, with their respective boolean values reversed.tap-to-click
andtap-to-drag
, should have their hyphens replaced with underscores, or alternatively, with base word alternatives.enabled
should be renamed toenable
, without the past tense.Additionally, more variables should have subcategories dedicated to them, for instance
kb_*
: