Open jtroo opened 2 years ago
I got an idea on how the UI could look like, and that's the result I scribbled in paint:
Generally, these would be main components:
It would be good to have a separate panel for aliases and macro editing. Or maybe somehow integrate it to key info panel.
I think it makes most sense to have browser-based UI for a set of features like these. Unless we need wanted to utilize low level keyboard grab or shell access or some other system-level thing, but I don't think it's necessary.
Thoughts? @jtroo
This all sounds good! I would agree that a web-based UI is sensible for easy cross-platform. The Linux/Interception device-specific configurations that would require testing locally to validate could be tested locally.
Just to add more info, one should be sure to check prior art in the space of GUIs for configuring advanced key remapping, e.g.:
One could take a look at Moonlander's Oryx
Frontend aside, I have a backend idea.
My idea is to develop a language server for kanata configs (obviously implementing LSP). It would be developed only as a vscode plugin at first.
If we were to eventually add an UI, such language server could already make most of the backend for UI configurator done (given that we already added features like code generation to the server)
And if we didn't develop UI configurator, such language server would be extremely useful alone anyway as a plugin for vscode or ported for other editors.
If we were to write it in rust, this could be used as a starting point:
https://github.com/IWANABETHATGUY/tower-lsp-boilerplate
Also, I just wanted to mention, that there are already some tools available to have better experience writing kanata configs:
vscode-kmonad-format - a vscode plugin for formatting deflayer blocks. It's for keymonad, but from my experience it works for kanata flawlessly.
vscode-kmonad - a vscode plugin for syntax highlighing kmonad syntax. It does work for kanata too, and although not perfect (e.g. most action names not highlighted), it's still a lot better than without syntax highlighting at all.
I would like to boost this
By the way, is the current kanata config parser capable of editing concrete syntax tree, i.e., load, edit, save without losing any formatting (roundtrip)? This would be needed so that you could edit your config via this UI configurator, but also in a regular text editor
By the way, is the current kanata config parser capable of editing concrete syntax tree, i.e., load, edit, save without losing any formatting (roundtrip)? This would be needed so that you could edit your config via this UI configurator, but also in a regular text editor
Today's parser passes the entire content of relevant files around in Rc<str>
with each SExpr
containing its own span, which is how error messages are created. But there is zero capability for edit/save today.
It's not implemented in parser yes, but parser today has a support for capturing metadata (spaces, tabs, newline and comments) you can take a look by searching SExprMetaData
in code. And while it's not even utilized in any way in parser as today, it's exposed for use in external tools
FWIW, I'm using it in my vscode-kanata extension, to construct metadata-aware S-expression tree and use it in formatter (see here). Perhaps it could be added to kanata-parser or even replace SExpr
? Obviously it's not as powerfull as full syntax-tree-with-medatata would be, but seems good as a starter (I already use it with some success)
Could be any of (or all of) the following: