We need a German QWERTZ layout for the Model 100 #1054
Comments
|
I received my model 100 and the QWERTZ keycaps and the layout does not match what i see in Chrysalis. In particular, "Ü" was missing on the base layer and some other keys were wrong as well so i corrected them as best as i could. I am attaching my JSON file with the QWERTZ layout for the model 100. |
|
"all layouts bundled with Chrysalis assume an US QWERTY layout on the host side" ... |
|
I am attaching a photo of the QWERTZ model 100 as reference |
That's understandable, but shipping N+1 variants of the QWERTZ keymap, for every single host-side layout is not feasible. Shipping a dozen or so variants isn't, either. So the compromise is to ship a layout assuming US QWERTY, and if that's not the one used on the host side, Chrysalis users can adjust it. It's a starting point, really, not much else. |
|
Are there really that many host side layouts? The QWERTZ layout is fairly standardized. |
|
There are 203 host-side layouts Chrysalis supports. We'd have to translate the QWERTZ layout to all of those. Even if we'd limit host-side layouts to what is reasonable, we'd still have to translate QWERTZ to about a dozen or more. And we'd have to do the same with the rest of the layouts Chrysalis ships with. |
|
It is clear that you cannot manage all possible combinations of keyboard layout and host layout, and I can understand the (current?) limitation to US QWERTY from a programmer's point of view but not from a user's one. I'm a professional programmer, but unfortunately not used to Javascript. Would it be possible to provide a mechanism that in theory could support all possible combinations, and let the set of supported mappings grow as they are provided by someone? I imagine Chrysalis could show what host layouts are supported by a selected keyboard layout (or vice versa), and maybe encourage users to create missing mappings. |
The mappings are stored in a JSON file, like this one, or this. The second is the more recent format, but the former works too. The important part in either is the keycode ( The US QWERTY keycodes are here. The As far as the rest of the supported layouts are concerned, they're generated by this script, from the CLDR data, which we imported from this place.
Maybe. Perhaps it could even be generated from the CLDR data, because it kinda already has most - if not all - the information we need, we just need to map it to the appropriate physical layout. Digging around the CLDR stuff is probably your best source of information. |
|
@algernon let's get a QWERTZ layout into Chrysalis ASAP? https://community.keyboard.io/t/model-100-german-qwertz-keycap-legends/5381/64?u=rpnfan is one version of the layout. I do think we probably need to have two versions of QWERTZ - one assuming the host OS layout is set to QWERTZ and one assuming it's set to QWERTY |
|
AFAIU there is only one meaningful setting: Operating System (OS) and Chrysalis set to German. I can think of no use case to expect the English keyboard as a system setting (which should be mirrored in Chrysalis normally, right?) From my understanding to be able to achieve certain characters with a keyboard the OS need to be set to the wanted layout. This makes the translation from the keycode to a character. For example VK_OEM_1 in Windows language or code 51 in Kaleidoscope language will result in the semicolon (;) when the OS is set to an US layout and will print an ö when set to the German layout. When the system layout is set to English one will not be able to translate any keycode to an umlaut, because they are not included in that specific layout (US International layout does, but that is a specific case). When someone is buying a keyboard with German keycaps (which can not be reordered!) he will surely want to type in German and access the keys in the way they are printed on the keyboard. Only German-speaking people will be interested in German keycaps / keyboard and they will surely use the German keyboard layout in the operating system and nothing else. The German keyboard layout is used in Germany, Austria and partially in Luxembourg. No one else uses that layout. In Switzerland they use a layout based on the German one, but add additional diacritics and have a few other differences (for example missing the direct ß) -- btw not too many people are using the Swiss German layout. |
|
I agree that the requirement to configure the host layout as US is not a good solution. There are good reasons to use a different host layout. Maybe we should think about a new concept for the definition of keyboard layouts. If I understand correct, the layouts like https://github.com/keyboardio/Chrysalis/blob/master/static/Keyboardio/Model100/layouts/qwerty.json define the mapping from physical keys to USB HID scan codes. This is what the keyboard has to do at the end. The keycodes will be translated by the host layout to a symbol, or might get interpreted directly by some software in special cases. Of course it is not feasible to distribute keyboard layout files for many Keyboardio/keycaps layouts multiplied by a number of all supported or "relevant" host layouts. What is the requirement of the user? I think in most cases, the user does not care about the scan codes. (Probably many don't even know that scan codes exist.) The user wants that pressing a key labeled "Y" results in the software displaying a "y" or "Y"(*) depending on the modifier keys. My idea is to use 2 types of layout definitions:
The user will select the host layout from the 2nd list and a pre-defined Keyboardio layout from the 1st list, if available, or create an own layout. If we assume There might be difficulties in special cases. For example on a Swiss German keyboard you can press shift and a key labeled "è" to get a lower case "e" with gravis accent, on a German keyboard with dead keys you have to press shift with the accent first, then the "E" without shift. This might require sending or not sending modifier keys independent from the physical modifier keys or generating / interpreting key sequences. If keyboards behave different on different OS we might need more host layouts, e.g. US layout for Windows, Linux, Mac. What do you think about this concept? Maybe this discussion should be moved to somewhere else because it is not specifically about German layout. It is a general question about using host layouts other than US or different host layouts with the same Keyboardio/keycaps layout. Bodo |
|
I absolutely did not mean to suggest that we expect German users to
configure their system keyboard layout as US QWERTY. And indeed QWERTZ on a
German QWERTZ host configuration is the priority here.
…On Wed, Dec 7, 2022 at 5:54 AM Bodo ***@***.***> wrote:
I agree that the requirement to configure the host layout as US is not a
good solution. There are good reasons to use a different host layout.
Maybe we should think about a new concept for the definition of keyboard
layouts.
If I understand correct, the layouts like
https://github.com/keyboardio/Chrysalis/blob/master/static/Keyboardio/Model100/layouts/qwerty.json
define the mapping from physical keys to USB HID scan codes. This is what
the keyboard has to do at the end. The keycodes will be translated by the
host layout to a symbol, or might get interpreted directly by some software
in special cases.
Of course it is not feasible to distribute keyboard layout files for many
Keyboardio/keycaps layouts multiplied by a number of all supported or
"relevant" host layouts.
*What is the requirement of the user?*
I think in most cases, the user does not care about the scan codes.
(Probably many don't even know that scan codes exist.) The user wants that
pressing a key labeled "Y" results in the software displaying a "y" or
"Y"(*) depending on the modifier keys.
(*)I call this keysym below.
My idea is to use 2 types of layout definitions:
1. A mapping from a physical key to a keysym. This is mainly what the
user cases about. There should be one for every set / arrangement of
keycaps or imagined *Keyboardio layout*.
2. A mapping from a keysym to an HID scancode (or multiple scancodes).
This is the reverse of the *host layout*. There should be one for
every supported host layout.
The user will select the host layout from the 2nd list and a pre-defined
Keyboardio layout from the 1st list, if available, or create an own layout.
Chrysalis could then check if / how all keysyms can be implemented by the
host layout and generate a mapping from physical keys including layers and
modifiers to USB HID scancodes, using key combinations or sequences as
necessary, and send the resulting mapping to the keyboard.
If we assume N Keyboardio layouts and M host layouts (or m relevant host
layouts per Keyboardio layout), we would only need N+M layout files
instead of N*M (or N*m) files, and it would be fairly easy to use the
same Keyboardio layout with different host layouts.
There might be difficulties in special cases. For example on a Swiss
German keyboard you can press shift and a key labeled "è" to get a lower
case "e" with gravis accent, on a German keyboard with dead keys you have
to press shift with the accent first, then the "E" without shift. This
might require sending or not sending modifier keys independent from the
physical modifier keys or generating / interpreting key sequences.
If keyboards behave different on different OS we might need more host
layouts, e.g. US layout for Windows, Linux, Mac.
What do you think about this concept?
Maybe this discussion should be moved to somewhere else because it is not
specifically about German layout. It is a general question about using host
layouts other than US or different host layouts with the same keycaps
layout.
Bodo
—
Reply to this email directly, view it on GitHub
<#1054 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALC2AGV5JMEM5GFO5FFW3WMCJJDANCNFSM6AAAAAAQSPXIME>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
My post, although triggered by the latest discussion, was also based on #1054 (comment): "[...] all layouts bundled with Chrysalis assume an US QWERTY layout on the host side, and German QWERTZ should too." and #1054 (comment): "There are 203 host-side layouts [...] Even if we'd limit host-side layouts to what is reasonable, we'd still have to translate QWERTZ to about a dozen [...]" Of course, we can create a German Keyboardio layout file that assumes a German host layout, and more layout files for every combination that anyone is willing to work on. For me it doesn't matter if the files are bundled with Chrysalis or shared somewhere else. This might be the way to get a working configuration soon. My thought is: Can we invent a better configuration system that would allow defining one Keyboardio layout that would automatically work with more than one host layout? Of course this would be an incompatible change, and modifying Chrysalis or creating an alternative configuration tool will probably need more time. This suggestion for discussion or research is the main point of my previous comment. |
|
This is the layout I'm currently using with German keycaps and German host layout. |
|
Thanks Bodo, I checked your file against the one from Neuhaus and mine. I forgot the ´-key (on the Any-position). In Neuhaus' file there is no way to switch to the Num-layer (#1), which is available in your json on the prog-key. I see no error and nothing missing in your file. So the default German layout file should either be the "plain" file from Bodo (post before this one) or version with additions: Optionally one could consider making the two additions I suggested in "my" qwertz-layout.
As far as I understand there is no price to pay for that, because the Prog-key will work always anyways!? So that would make the transition to the model 100 a bit easier IMO. I think the model 100 default layout should be as close as possible to the original layout. Then everybody can adjust the layout to his own needs, but would not need to do this.
This has the disadvantage of going away from a standard keyboard, where holding g will result in gggggggggggggggg… One could also offer two German layouts. One "plain" and one with additional tricks under the sleeve – of course nicely documented. I am now exploring the options myself. Maybe someone has ideas what could be a great addition besides Alt-Tab functionality? What do the German speaking people think? Should the documentation for the Germany layout be in German or in English? I am not decided yet what would be better. Regards, Peter |
|
I'm on my first day of using my Keyboardio, using the json from Peter. (Will check one of the others, later.) Am I holding it wrong, if I have the feeling the shift and ctrl keys need to be switched? |
|
Hi Nils, maybe better post in the forum instead here? I do not have access to my file. Maybe accidently Shift was changed there accidently compared to the standard position. I suggest you use the file from Bodo (see above) as a starting point. I, like many others, change the Shift either to one position inwards or to the most inner position, because for many the stretch is too large to the outer thumb key for such an often used one. |
|
I'm unsure about swapping I just noticed that ther are no |
Now I swapped the
I configured this change including As proposed by @rpnfan, I added The attached file contains these changes. Everyone is free to use it for any purpose. (Attaching screenshots as PNG or JPG doesn't seem to work. I get an error message "Something went really wrong, and we can’t process that file. Try again.") |
|
Hi Bodo,
For this I would move the CAPS on layer 2 to the normal position of CapsLock (left of A) and remove the Home/End left of A/Y key. The PrintScreen-function could be place on the P-key, to be easy to remember. It does not belong naturally on the left side (close to the mouse keys), so why not place it so it is easier to remember? Similiar the INS-key could be at another position. I would choose the I-key, but you have the media keys there already together and I would leave them for that reason. Then the INS-function could be place on the Ö-key, which is the last good position available. Why not use that for the INS-function which in some programs is frequently used? On the X-key (X-tract...) it is even counter intuitive IMO. I found that Scroll-Lock and Break (Pause) have been missing. I added those to layer 2 (LED-key and <-key). I do not know if somebody would miss those, but to be complete and close to the standard layout they should be included IMO. This should make to start using the keyboard as easy and straight forward as possible. What do you and others think? I attach the new suggestion and just call it Beta6 (after Bodo5 :-)). I think now everything is fine and nothing missing. If you all agree I wilĺ write the documentation how to use the default Germany layout. |
|
I just noticed that space cadet from Chrysalis does not make sense with the German layout. Left space will give ) and right will give =. |
|
Are their further comments or suggestions regarding the layout? I thought about the best language and think German would be more appropriate than English, because the target group are German speaking people only, because qwertz is only used in Germany and Austria. |
|
The switching from layer 1 (numpad) back to layer 0 does not work as I expected.(both with bodo-5 and beta6) Is layer 1 supposed to take into account |
One of the keycap sets available for the Model 100 is German QWERTZ. As such, we should have a layout bundled with Chrysalis that matches those keycaps.
For reference, this is roughly the layout:
https://www.dropbox.com/s/0rne7lic1k6tfza/Model%20100%20QWERTZ%20-%202022-07-07.pdf?dl=0
Some of the symbols were changed / fixed since, but those are just labeling, the positions are the same.
Keep in mind that all layouts bundled with Chrysalis assume an US QWERTY layout on the host side, and German QWERTZ should too. That will, however, show incorrect symbols for some keys.
The text was updated successfully, but these errors were encountered: