Comments (8)
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:
- 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.
- 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.
- 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.
- Key info panel - would display info about selected key, and you could edit key behavior here.
- 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
from kanata.
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.
from kanata.
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.:
from kanata.
One could take a look at Moonlander's Oryx
from kanata.
I would like to boost this
from kanata.
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
from kanata.
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.
from kanata.
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)
from kanata.
Related Issues (20)
- Unable to send key input due to key having not been physically released yet. HOT 3
- Bug: Release 1.6.1 macos_x86_64 executable isn't what it says. HOT 6
- Feature request: Show keystroke or can let other app know the real key is stroked. HOT 2
- Feature request: Can we have a more flexible unmod? HOT 1
- See if windows shift workaround can be compiled out for winiov2 HOT 1
- Bug: kanata does not work properly with listary HOT 3
- `release-key` releases both sides of a mod and not just one, e.g. `lctl` and `rctl` or `lmet` and `rmet` HOT 7
- Feature request: Compile-time conditional mappings HOT 1
- chordsv2 activation does not trigger early interruption of `tap-hold-press|release` HOT 9
- make macro-release-cancel also cancel virtual keys HOT 1
- Bug: switch's layer logic not recognized HOT 2
- Feature request: remove dependency on AutohotKey for EnableUIAccess
- Bluetooth keyboard cannot use without Chicony Keyboard attached on Thinkpad X1 Tablet Gen 3 HOT 9
- unable to set linux-use-trackpoint-propety HOT 3
- one-shot shift interferes with defoverrides HOT 5
- Feature request: chord toggle action HOT 1
- Feature request: homebrew
- Bug: special buttons on function row not working on macos HOT 2
- Bug: chord v2 overlapping chords HOT 2
- Bug: tray icons change randomly when layer changes by Meta key.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kanata.