hikari wayland compositor (https://hikari.acmelabs.space)
#7Expose modalities in the configuration file
Since we are a modal wm, why not extend the configuration to support that. This would make remembering/figuring out the correct finger-gymnastics for CSA key combinations, and allow using standard keys like hjkl for different actions.
This is my proposed syntax:
// equivalent to `bindings "default"
bindings {
keyboard {
...
"L+V" = enter-mode adjust-views
}
...
}
bindings "adjust-views" {
keyboard {
"k" = view-increase-size-up
"j" = view-increase-size-down
"h" = view-increase-size-left
"l" = view-increase-size-right
"S+k" = view-increase-size-up
"S+j" = view-increase-size-down
"S+h" = view-increase-size-left
"S+l" = view-increase-size-right
// ditto for snap...
}
}This syntax would also allow users to modify the keybindings for existing builting modes, or merge them with into new user created modes.
I'd be willing to work on this if you like the idea.
Also, great work! I've been having fun learning this new WM
I'm not quite sure if I understand your proposal correctly since it appear to assume modes that do not exist like "adjust-views"(?). Most things are handled in normal mode and there is nothing like an insert mode like there is in vim (which I decided against because it would really be annoying if you have multiple modal interfaces nested, e.g. neovim, fish (vi-mode) etc).
I thought about adding mode configuration but currently there is not much to configure there at the moment.
Modes that current exist are
group-assign-mode,sheet-assign-mode,mark-assign-modewhich is essentially only triggering an input box for the related indicator.mark-select-mode,layout-select-modewhich only accept a single character as in put and then exit.move-mode,resize-mode,dnd-mode(drag-and-drop) uses mouse position to do it's job
This is basically why I didn't do it yet because I don't really see any benefit. I'll leave this ticket open though because we can spit-ball some more ideas. Please keep in mind that we can not break the configuration randomly because this results in a major version bump (which we just had ;))
The idea is to allow users to create their own modes.
> it would really be annoying if you have multiple modal interfaces nested, e.g. neovim, fish
This keeps it up to the user, however, and allows them to choose which keys to use to enter and exit the different modes. Although, the way I was thinking of using it the escape key would be bound to exiting the mode in each of these nested interfaces. I don't think that that would be a problem though, since the user has explicitly entered the mode and would be aware of it. I can see how it could be confusing though. An indicator saying which mode we are in might be nice when we are not in the default mode.
> Please keep in mind that we can not break the configuration randomly because this results in a major version bump (which we just had ;))
Makes sense. The proposed configuration is an extension to the existing one, and wouldn't break anything. Of course, since the new configuration being added will need to be supported in the long term, I don't expect you to take adding it lightly.
> The idea is to allow users to create their own modes.
I think that's out of scope. I don't really see a lot of benefit there other than adding more complexity to the system. You could certainly implement this in a fork though.
Alright. The idea is to help keep bindings more organize, and since I though you already had code in for modes...
You can certainly give it a try. I probably really don't see a good way to make this work other than making usage more complicated by introducing more modes which would lead to more mental overhead for the user (at least from my perspective). I also think that mixes very badly with nested modal applications.
There is code for modes but this would also change a lot of the fundamental machinery and will surely lead to some design mismatches.
If I were you and REALLY wanted this I'd just give it a try and implement it in a case study and roll with it for a while. You might even end up with your own compositor in the end, which is cool. Personally I don't think I would merge the change though unless it proves to be really beneficial in the end, I'm having some reservations though but maybe you can prove me wrong.
- status set to closed
