hey there, I just got my UHK a few days ago and I’m still struggling with adapting to the new world. I’m one of these strange rare breads that can type pretty fast with a german qwertz layout and I assumed that I would be easily able to replicate that layout on the UHK with its flexibility. Most of that works, but I still have to regularly lookup some keymappings, esp. due to the reordering of the # key above enter. When I look at the UHK agent to lookup a key, it doesn’t seem to know anything about the Alt Gr mappings, is there a way to show that somehow? Generally it seems the agent only knows about the english iso layout and ignores the fact that I’m using a german layout on the software side of my linux machine. as such, the agent does not show any umlauts or the like for example. can I change that somewhere, and then ideally print out the layout such that I can more easily refer back to it as needed, instead of having to switch to the UHK agent software?
That’s very unfortunate. Can’t we at least add the ability to switch the UHK agent to a different layout, if you cannot query the host OS? And on Linux at least, you can easily query this:
I would expect the following excerpt from the linked article to indicate that ‘No’.
Without the exact per-key mappings, Agent would have to have a database of every single OS-specific layout, such as “French (Bepo, ergonomic, Dvorak way, Latin-9 only)” or “Russian (Ukraine, standard RSTU)”. We could extract such a database from the relevant Linux packages, but these layout names are not standardized, so they’re inconsistent across OSes, and the mappings surely differ in some ways.
The bottom line is that it’d take huge resources to implement the above, and we’d end up with a half-assed implementation, given that a perfect implementation is practically infeasible. Even if we were able to implement this perfectly, I don’t think it would be a good idea. I can foresee users complaining that they set up the é key in Agent, then plugged their UHK into another machine (featuring a different OS keymap), and the é key suddenly became a semicolon. Users should actually understand how things work when it comes to this topic.
Maybe it’s time for me to hack the UHK agent code to make it do what I would like
If you can implement the generic variant (that queries the scancode ↔ character mapping from the host OS), then a PR would surely be appreciated. I am always skeptical when Laszlo says that something can’t be done .
I think it’d be practical for Agent to expose alternative language mappings for the keycap languages we offer in our webshop, German included, but they’ll never work perfectly due to the issues mentioned in the linked article.
I’m in camp “perfect is the enemy of good”, the current situation is close to unusable for people not using an American layout imo. So even if there are fringe cases where an alternative approach wouldn’t work perfectly, I still think it would be miles ahead of the current situation.
Hallo Milian, was ist genau das Problem? “Nur” dass man in Agent nicht die Deutsche Belegung sieht? Das ist in der Tat nicht schön, aber an der Belegung als solches musst Du nichts beim UHK ändern. Du musst einfach schauen an welcher Stelle eine Taste liegt, was darauf gedruckt ist, spielt keine Rolle. Das ü liegt dann eben auf der mit [{ bedruckten Taste.
Du darfst für AltGr nur das RAlt auswählen, das sendet dann den richtigen Code ans Betriebssystem und wird bei Einstellung des deutschen Layouts als AltGr interpretiert.
That should be offered and is not really hard to accomplish, just need to map the English keyboard printings to the relevant German ones. I and others can have a look if you want to implement that in Agent. I do not see any problems in doing so from a technical standpoint. One must indeed provide a switch for the used OS, because on macOS some keys are mapped differently to Linux/ Windows.
@rpnfan the issue really is just one of discoverability. All keys “work”, but because the key layout is physically different from any German keyboard I’ve used in my life so far I cannot trust my muscle memory and need to lookup keys regularly. But that’s basically impossible, as I need to manually map the American keycodes in my head to their German equivalent…
As a UHK newcomer, it would help me tremendously if I would be able to print out a “mapped” layout, i.e. with the actual key codes that my OS will send.
Similarly, it’s super hard for me to figure out what the correct american key code is when I want to sent a German AltGr key. Case in point: today I wanted to add secondary { and } keys, and it took me multiple tries to figure out which American keys are the correct ones for that in the UHK UI…
I.e. this is all just extremely horrible UX for people with non-American keyboard layout. But as you say: once it works, it works - as long as one doesn’t look at the UHK Agent
PS: my physical key caps are blank, that’s not the issue here - I’m solely taking issue with what’s shown in the agent.
Only the #-key (German layout) changes position to the row above. The rest is exactly the same when you have the ISO version of the UHK. And of course the shape of the Enter key is different (in fact better, after getting accustomed to it).
Same here. Memorizing layouts was the easy part, but muscle memory is a different story. The Enter-key was my toughest challenge. Had to fight a life-long habit of hitting Enter on the upper-right corner. Which now belongs to a separate key altogether.
In hindsight, I am glad I did re-program my muscle memory, despite the struggle. Less typos and faster typing after I put German Umlaute closer under my fingertips. Also moved the “ß” away from its insane original position. It resides on the “s” key now, triggered by RAlt.
@rpnfan Sadly, there are many more keys that are off: AltGr is where I used to have Druck (never used), and instead Mod is taking the space for AltGr. I don’t have any arrow or page up/down keys anymore. There are no Fn nor media keys. Backspace is also a much smaller key than I’m used to and I cannot hit esc or del either. I am relearning this all with the new layout. I’m making this point just to illustrate that it’s really far more than just the #’ key that’s different to what I’m used to.
Ah, that is what you meant. Indeed there are quite a few changes needed to achieve the same functionality compared to a standard keyboard, because of fewer keys available! I was talking about the layout of the main keys which are similar, with the one and a half exceptions I mentioned (#-key and Enter form).
The AltGr-key is mostly on the same position on German full-size keyboards. But the arrows, Print and more you can never rely on a fixed position.
In the meantime I use a different layout and do not use qwertz any longer and adjusted my layers also. But the general idea of my posted layout is still valid and might give you some ideas. Also my linked article on hashnode might be helpful.
I will post my current layout hopefully in the coming weeks, still had too much going on…
Fast touch typing with a German keyboard layout (and blank key caps) here, too.
It helps if you know where the key currently is on your UHK and compare that to what is shown in the UHK agent at that position (7 and & in case of {, so you have to select 7 & where you want to type {).
I agree, though, that it would be easier with a German layout in the UHK agent.
However the macros it generates are for an older version of the firmware and I’m not completely sure that they work with current firmware. It’s also not integrated into Agent; it’s a standalone piece, more of a “proof-of-concept”.
Once Agent knows about different standard keymaps, maybe it could at least probe a few critical keys to differentiate which of the keymaps would most likely fit?
Sending scancodes from the keyboard to the host system is clumsy and unsafe, since you have no control over which keys get intercepted by the window manager and acted upon.
If you want to help with the issue, please investigate options to query the map directly from the OS, and write a poc in node / typescript ecosystem.
@mlac this request is popping up again and again. I am not sure if there are suitable platform independent npm packages to query the keymap, but querying the necessary info from the host OS is definitely possible, at least in some programming languages and some operating systems. I think it would be worth to investigate this further and try to implement the feature for those OSes that allow it.
@kareltucek Assuming there are proper OS-specific APIs to achieve a complete implementation, I think it’s way too much of a burden to make them work, and the incomplete implementation explained in the GitHub issue should satisfy the majority of users.
If there is a way to query the OS easily: great. But if not I would not bother and just give the option in Agent to choose the OS and wanted layout. This will go a long way already.
Autodetection is more of a nice-to-have feature, while showing the actual characters is much more than nice-to-have. It is not needed, but makes life much easier.
When one thinks of extending that concept one can offer the option to define a custom keyboard layout somehow. That will allow to support any language and also custom layouts, including the usual suspect like Dvorak, Colemak (which is way overhyped IMO), Neo, AdnW and others.
To cover the typical use cases one would need to define the key-character mappings for unshifted, shifted and AltGr-layer at least. When one wants to go the full way also Shifted AltGr modifiers and the Japan based ones (Kana and I think there is one or even two more) could be supported.
I beg to differ. Ever connected a USB keyboard to a Mac? They ask you to press the key next to the left shift key, that helps them to determine whether you have an ISO or ANSI layout.
I think Agent could just ask the UHK to send a few strategic keypresses to determine which of the standard languages is active on the host OS. No need to press any Windows, Command, Option etc keys (which may trigger host OS actions). Just press some alphabet keys to check QWERTY vs. Dvorak vs. Colemak layouts, e.g. press "Q W A Z ; ’ P " (US layout) keys and you will know what language-specific map is active. From that information, auto-select one of the available options.
So, as a first step, give the user a list of languages (in Agent) to select from.
Second step, have an “auto-detect” function that detects and auto-selects one from the list.
This will satisfy >95% of users that are asking for language selection.
The remaining cases are very special, and affect super power users with completely non-standard keymaps who will hopefully be smart enough to learn how to manually work around their host key mapping.
.
