Non-US layout support

[mondalaci]

Some non-US users have trouble finding their desired scancodes since Agent only exposes US key symbols.

Let's include the following scancode to symbol mappings according to the offerings of the UHK 60 product page:

• UK
• German
• Nordic

On the Settings page, Add a "Key language" option above the Theme option, including the default "US" option and the above options. This is an Agent setting, and it's not part of the configuration of the UHK.

According to the Key language option, visualize the key labels and populate the Scancode dropdowns of the keymap and macro pages accordingly.

[seblovett]

I think this also manifests itself in macros. I'm on a UK layout, and added a macro to type my email address. However, the @ symbol gets typed as a double quote (").

[mondalaci]

Yes, it's the same issue.

[kareltucek]

Is it? According to the above specification, this is agent only thing 🤨.

[mondalaci]

It's an OS layout scancode-related issue, but the specification doesn't address text macro actions, which would be harder to address due to translating characters to AltGr combinations and such.

[mortenbentsen]

Consider this a bump/+1 on this issue/feature request.

Being from the nordics, and using a mac, I feel like I'm at difficulty 11 just getting down the bare basics on the UHK :P

[piratk]

This has been an big issue since day one of macro-support for UHK, at least for all non-US keyboard users. For Windows users, I suggest having a device driver that provides some translation support for the currently used keyboard language. If it does the translation while programming the keyboard or while running the macro is not really important for many users, all though in the former case the macro support would still work in non-windows environments, kind of anyway.

[rpnfan]

I have seen that Oryx has a nice solution to support different locale keyboards. You can use that as an inspiration. One can play around with Oryx without a keyboard.

https://configure.zsa.io/home

[mondalaci]

Thanks for the idea! I wasn't aware of Oryx's solution, and I can see its merit. It's a bit misleading, though, because according to the OS locale, the same scancode can translate to numerous characters. Agent and the UHK would also have to store per-scancode locale metadata. Per-layer or per-keymap locale metadata might make more sense, but I can't see the use cases clearly.

[rpnfan]

because according to the OS locale, the same scancode can translate to numerous characters

That is exactly what is nice here. You choose one locale, not several, in the settings (cog wheel - lnternational). Then Oryx will display you the characters which are available for the given locale setting. So nothing is misleading, in contrast. You just have to match your OS keyboard setting in the Oryx settings. One locale setting is "US International", which is nice, because that can be a good keyboard locale setting for many multi-lingual people. It then displays all characters available with that US locale.

AFAIU you can not switch complete layouts with ZSA keyboards, so that is something the UHK would need to handle in Agent as well -- matching the locale to a specific UHK layout. But then this would be the perfect solution I think.

[mondalaci]

By "UHK layout", I assume you mean UHK keymap. Keymap-specific locales would probably make sense.

[rpnfan]

Yes, I meant keymap indeed. :-) ZSA keyboards only seem to have one, you can not switch to others -- without reflashing the complete board. At least that was my impression. So here the UHK would need a mapping between keymap and locale. In Oryx you could turn on multiple locales, but that does not make sense. From a UX point of view those should be implemented with a radio button.

When this concept is implemented you could start with German, UK, US International and then add other locales as needed. Oryx now seems pretty complete with about 30 locale settings covering a large portion of possible users.

[mhantsch]

Once you have that locale config button, you could then add a kind of Auto-detect that I suggested a while ago. Agent would trigger the UHK to send certain scan codes, and check which characters it got sent by the OS. Agent would use this to check a few specific keys and then select one of the supported locales.

[mhantsch]

Some more thoughts on macros and locales.

For locale support in macro commands (I am thinking of write, tapKey, tapKeySeq etc.), the firmware would need to know what locale the host is using. This is the same setting as you would configure in Agent. Maybe Agent should send that setting as part of the config to the firmware.

The firmware would have a static table for each of the possible locale settings, and translate the characters from write and tapKey to scancodes based on the table.

For example, if you set your locale to German, the firmware would allow tapKey ä because the translation table would tell it to send scancode apostropheAndQuote. With a different locale, ä might be invalid, and the firmware would either throw an ERR or replace the character silently by an 'unknown symbol' character (e.g. questionMarkAndSlash).