search

ijprest / keyboard-layout-editor

Web application to enable the design & editing of keyboard layouts
http://www.keyboard-layout-editor.com/
Other
1.29k stars 242 forks source link

Scancodes #192

Open miloush opened 7 years ago

miloush commented 7 years ago

I believe the layouts should be able to carry information about the scancodes the keys generate. That would allow the generated layouts to be used in applications that generate actual input, and it is also a critical information for manufacturing physical keyboards based on the layouts.

iandoug commented 6 years ago

I agree. However things get more complicated when firmware like QMK comes into the picture, where you can make any given key pretend to be a different key or key combination. I have been thinking about these issues for a while.... no simple solution yet. It will require updating the JSON files, and that may break other services that use these files as inputs (eg Swill, QMK, probably others).

keturn commented 5 years ago

The simplest change to the file format would be to add a new scancode property to the keycap metadata object for each key; old parsers might be able to read these files just fine, as long as they ignore properties unknown to them.

There would be a significant impact on the files, though, since the current format seems to be optimized for the assumption that most keys will not have metadata objects. Whereas you probably expect every key to have a scancode.

So if you've ever thought about introducing a new serialization format, this would probably be the time to do it.

(I know I've found that the current format that mixes objects and strings in the same Array to be a little hard to parse with JSON libraries that expect an Array to have a consistent type.)

HughP commented 5 years ago

Has anyone looked at the new version of the LDML schema from CLDR? CLDR v22 added an XML specification for keyboard layouts, which I know was recently updated. relevant links: http://cldr.unicode.org/index/charts/keyboards http://cldr.unicode.org/index/cldr-spec/json http://www.unicode.org/reports/tr35/

iandoug commented 5 years ago

Interesting. Various people/groups have been working on some sort of unified "keyboard layout language" which would support the different OS as well as existing tools (eg KLA, KLE, assorted firmware solutions for home-made keyboards, assorted keyboard-remapping tools for different OS) but it's a complex problem.

I see your link above somehow mentions Android and Mac but not Linux/Unix ... curious. Maybe just a demonstration of the difficulty :-)