Add a UI configurator

[jtroo]

Could be any of (or all of) the following:

• Browser-based
• TUI
• GUI

[rszyma]

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:

1. Keyboard visualization panel - that's obvious - you could see what buttons/functions are assigned to each key, add/see/modify layers, drag-and-drop keys around to swap them, blah, blah... i.e. usual stuff you'd expect.
2. Text editor - not a plain text editor, but I imagine it would be useful to have something like that, even if it's gui configurator, because the config format is human-readable and is formatted too. Also it would be useful to have, because initially not all features would be available GUI part of the program. Generally my idea is, when you remap a button (or do any other modification), the config in the textbox would be updated in real-time to reclect the changes. And vice versa - you could change something in the textbox and see the changes on the visual layer.
3. Search panel - filter by key type and search for keys/mods/functions. You could drag-and-drop from here to a specific key on the keyboard panel. Also user defined macros and aliases would be searchable here.
4. Key info panel - would display info about selected key, and you could edit key behavior here.
5. Visualization metadata panel (optional) - a component to display and edit visualization metadata for each key, and it's only for adjusting rotation, correcting x/y position of key and key size. It could be something like "properties" panel here. This metadata could be saved e.g. in comment above defsrc block.

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

[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.:

• https://github.com/keyboardio/Chrysalis
• https://config.qmk.fm

[ShrykeWindgrace]

One could take a look at Moonlander's Oryx

https://www.zsa.io/oryx/

[rszyma]

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.

[ibrahimkettaneh]

I would like to boost this

[eugenesvk]

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

[jtroo]

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.

[rszyma]

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)