qmk_configurator
qmk_configurator copied to clipboard
Display rotated keys in the configuration screens
Overview
QMK renders a representation of the keyboard in the configurator. If QMK could render keyboards with rotated keys, they would look more similar to the physical keyboard.
File format
QMK needs to store this data somewhere.
The current layout section of info.json has fields for specifying rotation: r
, rx
, ry
and the future info.json format has that place available as well.
Currently no info.json
files in the qmk_firmware/keyboards have rotational data stored. One reason is because the files currently render better when no rotational data is populated.
Rendering
Currently the configurator renders the keyboard without rotated keys. It needs to be updated to take rotational data into account. It is imperative that the configurator renders existing info.json
files the same way as it does before this change.
Rotation (r
) currently defaults to 0
or no rotation. This makes the transition easier. Reading older info.json
files will default the keys to no rotation. Which is the current behavior before this change is made.
This should be committed before the other changes are made. Introducing this change by itself results in no change. Which is good in a transitional process.
Populate info.json
files
The configurator can only render rotated keys if the info.json
has that rotational data.
A popular layout editor, keyboard layout editor, has a raw format, kle.json, that has fields for specifying rotation as well. (also r
, rx
, and ry
). This file is often a good starting point for creating keyboard layouts.
Currently [kle2json] converts from kle.json
to info.json
format but does not transfer the rotational data across. The kle.json
files typically have rotational data, so this is a good place to start and help developers understand how these values work. It is also similar to the keyboard layout editor, so the developers are probably familiar with these concept.
This change needs to be made after the configurator changes. Populating data in the info file when the results can't be seen, or worse when the results look bad is not a good situation.
please see kle2json PR
note: the info.json
files do not need to be changed. Developers only change them if they want the added rotational feature.
configurator changes
Defining the rotations
alice keyboard kle and an alternate kle were developed in keyboard layout configurator.
The alternate was mostly developed in the raw pane, which is not typical for developing a kle.json
getting the info.json
file
The above kle.json
files were passed throghkle2json
with the changes from kle2json PR applied. No modifications were made to these info.json
files. Typically, they will be tweaked by the keyboard developer.
Results
Original Alice info.json
The original alice info.json still renders the same.
![configurator_orig_info_json](https://user-images.githubusercontent.com/1930/80922213-8616ed80-8d49-11ea-922e-0ef2496463f8.png)
alice keyboard kle
The new alice info.json
displays rotated keys:
![orig_kle_configuration](https://user-images.githubusercontent.com/1930/80681955-a6b41e80-8a8f-11ea-93d5-efe63c37867a.png)
Alternate kle.json
The hand generated info.json
also displays rotated keys:
![alice_confiturator_drag_drop](https://user-images.githubusercontent.com/1930/80681893-8e440400-8a8f-11ea-9e8d-4fe9bc386064.png)
This is a great conversation starter. There's some interesting ideas here. It actually points to some refactoring work I'd like to do around BaseKey that makes it less efficient that it really should be. Especially as some earlier work has now made rendering much slower than I think it should be.
I'll let @skullydazed weigh in on the JSON changes. I think this actually probably goes counter to some work he's doing right now to support multiple layouts. I think transform is the right way to do this, and I just ran an experiment where I replaced top and left with transform and it works largely the same.
Having said that, width and height per key have to go, and I have an idea how to do that, involving a new CSS spec called css custom variables. This should clean up the DOM significantly. It should make rendering more efficient as we can use CSS classes instead of per element styling.
yea, transform rx,ry rotate(r) transform y,x
will work for all. I was trying to change as little as possible with the top/bottom
also, I'm not sure why you don't want 0's (i.e.: top:0
) in the style. removing that restriction would simplify the vue code. (but you are more aware of these tradeoffs than I am.)
yea,
transform rx,ry rotate(r) transform y,x
will work for all. I was trying to change as little as possible with the top/bottomalso, I'm not sure why you don't want 0's (i.e.:
top:0
) in the style. removing that restriction would simplify the vue code. (but you are more aware of these tradeoffs than I am.)
0 is the default, making the style parse code that doesn't do much isn't necessarily helpful. It's a micro optimization at best. transform has one downside, the transition code doesn't seem to know what to do with it, so we lose some of the snazzy animation we got for free by using simple css attributes.
I'm also thinking of doing away with the calculations and just using transform: scale
I tried hard to follow the layout project guidelines and discussed the rotation ideas with him.
This is my first time with vue, and my javascript is average. So any direction you want me to take, I'm all ears.
This https://github.com/qmk/qmk_configurator/pull/726/files might interest you. I'm thinking about how to get rid of the height and width explicit values and replace them with css classes