Feature Request: Add European layouts to the onscreen keyboard

[Abraxas-Knister]

I want to setup a keyboardio/atreus with a neo2 inspired layout, and since I'm German it should be able to actually type the included German ÄäÖöÜüß (capital ß is included in actual neo2 but not required for me).

If I understood the configuration process correctly, I think I need to (a) tell the OS that my external keyboard is intended to be mapped as a qwertz keyboard and (b) configure my layers to use key (combinations) that would create the correct result on a German qwertz keyboard.

For that to be a pleasant process it would be nice to have the option to have the ANSI or ISO onscreen keyboards in the configurator appear with labels matching the target keymapping in the OS.

Examples:

• to type '>' on the ISO qwertz layout you press the key right of the left shift (labeled '\|' in the configurator) together with shift.
• to type ']' on the qwertz layout you press the number row 9 together with AltGr (which hopefully corresponds to right alt), but 9 is labeled '9(' in the configurator
• to get '\' you press AltGr together with the key right of the 0 in the number row, which is '-_' in the configurator.

Also you're probably easily tempted to just drag and drop the '{' from the bottom row in the configurator, but that wouldn't work as expected: it stands for shift plus '[', where with '[' the key to the right of 'p' is meant, which is 'ü' on a qwertz layout. So from '{' you get 'Ü'.

It would therefore be nice to have fast access to common punctuation or symbols for the european qwerty layouts too, eg

• '@' is AltGr+q
• '(' is Shift+8 (instead of Shift+9)
• '?' is Shift plus 'ß' which is right of 0
• '^' is on its own key left of 1

[yanfali]

As has probably been explained to you on discord, all keyboards are QWERTY/ANSI by default on the wire. All layouts are a function of the operating system and vary from OS to OS when you set the locale. It would be quite a lot of work to make this work in the UI. Here's the mappings we provide for the compiler per locale

https://github.com/qmk/qmk_firmware/tree/master/quantum/keymap_extras

To give you a taste of how much work this would actually be. To make matters worse, there are actually 3 variants for German when you factor in Swiss, and MacOS.

Contributions are welcome.

[Abraxas-Knister]

I didn't visit the discord, should I have?

Firstly a question to make sure I understood the mapping process correctly: will my atreus generate an 'ö' on the screen when I set the key below the home position of then left ring finger to generate an '; :', and will it genereate an '{' if I set the relevant key to right alt plus number row 7 (given I have qwertz in the OS)?

So what would need to be done is

• give the user a menu for choosing the layout
• map the layout in that menu to the correct header
• load the header into the firmware generator
• display the correct layout (ie make little icons for the keys)
• link the clickable keys on the layout to the correct #defined keycode (or macro) in the loaded header
• do the same thing for the shifted and alted symbols in the shortcut list below
• don't forget to make little icons for the missing symbols (eg '[')
• repeat 100 (roughly estimate of number of layouts for which headers exist)
• probably loads of work I didn't think of because I have no idea

really does seem like lots of repetitive stuff with somewhat little payoff.

Would it be possible to include these headers from within the UI to be able to search for things like 'ALTGR(DE_7)' (ie what would generate '{') in the UI keycode search bar without needing all the graphical stuff? This seems like it might be a much more practicable fix.

[yanfali]

I didn't visit the discord, should I have?

Absolutely. Having this conversation over github is a bit limiting.

Firstly a question to make sure I understood the mapping process correctly: will my atreus generate an 'ö' on the screen when I set the key below the home position of then left ring finger to generate an '; :', and will it genereate an '{' if I set the relevant key to right alt plus number row 7 (given I have qwertz in the OS)?

It's a bit less complicated than that, since the API doesn't actually know or care about locales, it only is concerned with keycodes that eventually translate into USB HID values. The locale is an abstraction, only for humans. Where ISO has decided what keycodes map to what values in a locale. The underlying operating system only ever deals with ANSI keycodes and translates those keypresses on the fly for the User interface.

To make configurator simulate that behavior, we would have to make it support every single locale the OS does. That's not an insignificant amount of work. Firstly to maintain those mappings - which are separate from the firmware repo, and secondly to integrate that into the UI where it could both autodetect your locale from the browser headers and be over-ridable per session.

Essentially the configurator would be lying to you about what keypresses it was receiving. This has complex interactions with the locale since the browser is also being presented with locale values by the operating system. I'm not saying it couldn't be done, it's just a metric ton of additional work.

So what would need to be done is

• give the user a menu for choosing the layout
• map the layout in that menu to the correct header
• load the header into the firmware generator
• display the correct layout (ie make little icons for the keys)
• link the clickable keys on the layout to the correct #defined keycode (or macro) in the loaded header
• do the same thing for the shifted and alted symbols in the shortcut list below
• don't forget to make little icons for the missing symbols (eg '[')
• repeat 100 (roughly estimate of number of layouts for which headers exist)
• probably loads of work I didn't think of because I have no idea

really does seem like lots of repetitive stuff with somewhat little payoff.

Would it be possible to include these headers from within the UI to be able to search for things like 'ALTGR(DE_7)' (ie what would generate '{') in the UI keycode search bar without needing all the graphical stuff? This seems like it might be a much more practicable fix.

It might be possible to have the API load up all the mappings into an API end point and then we could potentially have a way to display these mappings on the UI or take advantage of them. But that would require effort and work on the API by our API developer, as in the ideal case the API is a single source of truth; what I would want to avoid is having two sets of data representing the same information.

As we're a volunteer driven organization, it really depends on time and inclination of individuals to make this happen.

[Abraxas-Knister]

Absolutely

sorry about that. Will definitely pose further questions on discord instead of polluting this channel. I found a permanent invite link for the server somewhere on reddit, but it would probably beneficial to put it on qmk.fm too (I didn't even know there was a discord).