Please add Kanata as input source

[newsve]

Pretty much the title; fwiw, I fully switched to Kanata because:

1. Same feature-set as QMK/ZMK, also with fine-tuned tap-hold behaviors
2. Runs on OS-level, so as well on your notebook keyboard
3. One file runs on all OSes (Win, Mac, Linux)
4. Extremely elegant, terse, compact, lisp-like config lang
5. Fastest iteration thanks to hot-reload your config; updating Katana is one git pull && cargo build
6. Actively maintained

It would be great if Kanata configs could be parsed too, so we could automate the process of keymap drawings just based on the config.

[caksoylar]

While I know of Kanata I haven't used it myself, I'll have a look. I'd like to support it but it mainly depends on how hard the parsing will end up being.

[caksoylar]

After an initial glance, here is a question (for you or anyone else that would like to visualize a Kanata map): What physical layout should be used?

Kanata lets you easily map just a subset of the keys, and it is not associated with a specific keyboard shape. My initial thought would be to always use a ANSI 104 keyboard as the physical layout, since that could be considered the "generic" keyboard and we know where each keycode goes, at least assuming US keyboard layout. In this case, we could show the full keyboard with the src keys replaced with the mapped ones, or, we could leave the non-mapped spots empty.

I can imagine people would still want to select their own physical layout. But without knowing their firmware mapping, we wouldn't know which key positions are overriden by the Kanata keymap. So I can't see how that would work without additional input data.

[newsve]

Thanks for looking into it!

What physical layout should be used?

I can talk only for my case but it's a typical 60% US ANSI or US mapped ISO because this is also what you find also on notebooks.

Reason is that I don't lose any muscle memory when switching to a notebook. I don't have perfect key placements like on a Corne or thumb keys but in terms of finger movement and overall feel I come very close with my mapping (it's basically a 40% on a 60% with tons of magic). And again, without efficiency losses when switching back and forth a notebook and any external, fancy mechboard.

I can imagine people would still want to select their own physical layout.

Yes, even when using it with such thing as a Corne, it would offer faster iteration than both QMK and ZMK and maybe also better control of tap and hold than QMK. And much terser confgs.

So I can't see how that would work without additional input data.

What about letting the user import KLE data and only for the physical matters, so positions and og keycodes. This would need to be done only once since this doesn't change once a user settled with one physical layout (for a while at least haha).

Not sure if this all fits anymore into the scope of your tool which I just found yesterday but Kanata is really onto something. I use one file for all my devices with both macOS and Windows pulled and synced from a central storage, no need to flash all your keyboards on every change, it's a dream. And again, these iteration times are necessary, you code, feel that something is wrong, switch to your kanata file, change and code on. This is a matter of a few seconds and also for complex remappings.

Having now a tool that could create wonderful pics on save (or on git push haha) would be sick and I see a future where everyone has their layout published with auto-generated layout maps from your tool.

[caksoylar]

I can talk only for my case but it's a typical 60% US ANSI or US mapped ISO because this is also what you find also on notebooks.

I imagine so, the problem is it doesn't cover all possible src keys, e.g. if people use f-keys in their defsrc. Maybe I'll do a staged approach, where it defaults to a 60% and picks larger layouts (65%, TKL, 104) if it encounters a key not covered by the smaller layout.

What about letting the user import KLE data and only for the physical matters, so positions and og keycodes. This would need to be done only once since this doesn't change once a user settled with one physical layout (for a while at least haha).

That would be possible in theory, but I'd like to not deviate from the current physical layout paradigm. But that doesn't contain the OG keycodes info, of course. Given that I imagine laptop keyboard use case will be dominant, it might not be worth investing much time into custom physical layouts, at least initially. Feedback is welcome on that.

The good news is that the keymap seems relatively easy to parse using the existing pyparsing dependency, so that's great.

[caksoylar]

Related discussion for anyone else who checks this issue: jtroo/kanata#1003

[newsve]

fyi, I answered in the other thread...