Julow
[feature request; discussion] advanced nixos-like config file(s)
~~I don't know how to approach it as I'm rewriting this suggestion for the 7th time.~~ Basically everything as a config file or multiple linked config files. I never used nixos extensively to know how it's like, I just like the idea.
It is not a santa list of features but rather a robust framework that may help in percise/convenient configuration and sharing of layouts. Why did I say that it's not a santa list? Well, because I already see some features that can make use of it such as:
- default setting override (e.g. smaller margin gap for this layout only)
- layout relation override (e.g. changing out the base numpad layout, or adding new screens)
- etc... (this is where I would usually give up, I have too many examples of using it, and some of them are alresdy open feature requests that I usually give up looking for)
discussion and criticism is welcome *sorry in advance if there is a github discussion tab that I missed
Advantages:
- The .INI file could be copied from phone to phone
- Advanced options could be defined that might be too intimidating for new users of the Settings menu
Any "For this layout only" conditionality should go in the XML of that layout.
"Multiple linked config files"? So I can have a file of my preferences across all devices, then another for my preferences for tablets? I'd opt for simplicity over such elegance.
Any "For this layout only" conditionality should go in the XML of that layout.
I see a possibility of referencing an xml file or storing such xml layout inside the very config
"Multiple linked config files"? So I can have a file of my preferences across all devices, then another for my preferences for tablets? I'd opt for simplicity over such elegance.
I meant config files that point to other config files. Something like #include <> in c or as I mentioned config files in nixos (I guess .bashrc can count to some extent as well).
Meaning thst you can have everything in one big file or split it into multiple. Furthermore easier copy of custom layouts that require different base settings (margin is a clear example mentioned); I imagine base setting override to be hierarchical (e.g. the value is N, until changed somewhere down the line).
I like the idea of an editable config file. I think this can be related to https://github.com/Julow/Unexpected-Keyboard/issues/856 https://github.com/Julow/Unexpected-Keyboard/issues/979 and can be desirable for users that like reproducibility and not loosing their data.
A system like the one in Nixos however is totally overkill. All of what you ask are separate features and don't require fundamental changes to implement.
default setting override (e.g. smaller margin gap for this layout only)
Would you like to propose an implementation for this ? I think this will require a lot of work but fortunately no challenges.
layout relation override (e.g. changing out the base numpad layout, or adding new screens)
I suggested in the past to give a name to layouts and to allow defining "goto" keys https://github.com/Julow/Unexpected-Keyboard/issues/678 https://github.com/Julow/Unexpected-Keyboard/issues/810. This doesn't require putting all the layouts in the same file but that could make edition easier.
It seems that many people want to customize the number pane (https://github.com/Julow/Unexpected-Keyboard/issues/459 https://github.com/Julow/Unexpected-Keyboard/issues/808) so this would be a very nice addition.
I meant config files that point to other config files. Something like #include <> in c or as I mentioned config files in nixos (I guess .bashrc can count to some extent as well).
Thinking in term of files overcomplicates things. A single config file should be enough for all of this. Easier navigation in the config should be provided by the UI (edit layouts individually) rather than a complicated config format. Layouts being defined in XML, they are perfectly extensible and it should be easy to expose a way to override preferences.
A system like the one in Nixos however is totally overkill. All of what you ask are separate features and don't require fundamental changes to implement.
I just wanted to set the tone, I got too much of them somewhere in the clipboard pins from countless drafts. I'll search for any worthwhile ones and add here. It's just that issue section isn't a place for such santa lists in my eyes, and it's better to have several boxes to tick instead of one.
default setting override (e.g. smaller margin gap for this layout only)
Would you like to propose an implementation for this ? I think this will require a lot of work but fortunately no challenges.
Yes, I arrived to this thought while making a wide horizontal layout that didn't rhyme well with global margins that I configured with builtin layout in mind.
I also once tried making a layout with exactly 1 unit sized keys. Sure, only ~1% will find it useful to define the keyboard size by it's key size and make the margin freeform, but that's a topic for another idea.
layout relation override (e.g. changing out the base numpad layout, or adding new screens)
I suggested in the past to give a name to layouts and to allow defining "goto" keys #678 #810. This doesn't require putting all the layouts in the same file but that could make edition easier.
It seems that many people want to customize the number pane (#459 #808) so this would be a very nice addition.
These suggestions pretty much nail the point. I may have something to say, so I'll read into them.
I meant config files that point to other config files. Something like #include <> in c or as I mentioned config files in nixos (I guess .bashrc can count to some extent as well).
Thinking in term of files overcomplicates things. A single config file should be enough for all of this. Easier navigation in the config should be provided by the UI (edit layouts individually) rather than a complicated config format. Layouts being defined in XML, they are perfectly extensible and it should be easy to expose a way to override preferences.
Only positive thing about splitting configs is probably trying out new layouts while keeping some of user's settings persistant, while overwriting other ones. I guess it's not that much of a problem to tinker with newly downloaded layout after all, especially with addition of swappable configs.
Ran into this having to reinstall UK and realised some of my settings weren't persistent, and went down the rabbit hole of custom layouts.
I hacked up a NixOS module (nix-on-droid compatible) for declaring layout options and custom key mappings yesterday - I'll clean it up and make it public shortly and link out to it.
It doesn't help with the many settings of UK that aren't exposed in the XML layout but does go a lot of the way to enabling composable configurations (i.e. take an existing layout and declaratively change a few of the corner mappings, modmap behaviours, inject a key row from a different layout, etc).
Per this thread, exposing more UK functionality as XML attributes on keyboard/key/row, and having UK treat a setting as being overridden if defined by the currently enabled layout, would basically go all the way.
