People ask from time to time whether we provide a numeric keypad. The answer is no, but one can create a virtual numpad very easily in Agent, the configurator application of the UHK.
See the following screenshot. The numpad is mapped to the Fn layer, and its keys are laid out in a familiar fashion.
The big advantage of a virtual numpad is that one doesn't have to reach out all the way to the other side of the keyboard. This results in increased productivity, and the mouse is much closer, too. That is, if you even use a mouse after mastering the UHK mouse layer.
We get requests from time to time to provide a carrying case for the UHK, and we'd like to offer a case, but there's way too much on our plates nowadays, and we're not sure when we'll be able to offer one.
Fortunately, this didn't stop our awesome customers from making their own cases, and boy, these cases are amazing! I'll feature three cases below.
If you have a UHK without a UHK palm rest, then look no further than @contracode's case, and make sure to check out his tweet for instructions.
UHK + Palm Rest soft case
If you have a UHK with a palm rest, then Stephen Walsh's case is probably the best choice for you. See his tweet.
UHK + Palm Rest hard case
If you have a UHK with a palm rest and you're willing to spend more on a robust case, then Cole Chamberlain's case should be a great option which he made from a Pelican 1085 hard shell case. Check out the relevant Twitter conversation.
We're never ceased to be amazed by the ingenuity of our customers. We're still not sure when we'll be able to provide an official UHK case, but the above should be more than adequate in the meantime.
Although we did our best to make Agent as intuitive as possible, we get questions from time to time. By far the most usual question is how to exchange the keys of the bottom row.
Let's say you want to exchange Alt and Fn.
Now select the base layer of your default keymap in Agent. You should see something like this:
The important thing to understand is that each key has an associated action. Let's click on Alt.
A popover appears that contains the type and properties of the action. The Keypress tab is active so this is a keypress action (type) featuring no scancode and the left Alt modifier (properties).
Now let's see the action of the Fn key by clicking on it.
Now the Layer tab is active which means that it's a layer switch action which activates the Fn layer while holding this key.
You simply have to exchange the actions of the Alt and Fn keys by clicking on them and setting their action type and properties. Make sure to check the "Remap on all layers" checkbox for modifier keys before clicking on the "Remap key" button.
Lastly, click on the "Save to keyboard" button in the bottom right corner.
That's about it! Happy remapping!
We get this question from time to time, and the answer is not so obvious as one might think. I'm about to explain it in depth, but first I'll give you the short answer in case you're in a hurry. Please consider the relevant tooltip of Agent:
Hopefully, this explains what to do. You're welcome to suggest a better phrasing in the comments, but this is the short and sweet version. And now on to the more detailed explanation.
Characters vs Scancodes
The most important thing to understand is that USB keyboards (the UHK included) do not send characters to your computer. No, Sir. They send scancodes. When you press a key, a scancode of 1 to 255 gets sent to the computer. It's not a character, but a number!
Now think about this: There are 255 different scancodes which must be mapped to more than 100,000 characters that are used on planet Earth! How so? This is how:
Your operating system translates scancodes to characters based on your actual operating system keyboard layout.
Let me give you an example to make you realize the crucial role of your OS layout. Let's say that an American, a German, and a Russian user purchase USB keyboards of the same physical layout. Now let's take the semicolon key according to the American layout. On all three keyboards, when pressing this key the scancode 51 gets sent to the computer, yet, the character ";", "ö", and "ж" appear of the screen of the American, the German and the Russian users respectively, merely because they use different OS keymaps.
When it comes to mapping scancodes to characters, the situation is actually slightly more nuanced because modifiers also affect the mapped characters. For example, on the US layout Shift + 4 produces "$", and on the Hungarian layout AltGr + U produces "€", but this doesn't alter the nature of the beast.
There's a mechanism called "Alt codes" which allows users to produce various accented characters in a way that is (mostly) independent of the current OS keymap.
- On Linux, press Shift+Ctrl+U which prefixes your cursor with an "u", indicating that now a unicode number is expected. At this point, enter "2764" followed by Enter and ❤ will magically get inserted. Linux Alt codes are the most powerful and most standard given that they're backed by unicode numbers.
- On Windows, first you have to have Num Lock enabled. Then hold an Alt key and press a Windows-specific numeric code, and finally release the Alt key at which point the relevant character will be included. Merely 375 different characters can be included this way.
- On Macintosh, there's also a similar mechanism that is better called Accent Codes. Let's say you want to put an accent to the "o" letter. You press Option+E, then press "o" which results in "ó". The set of characters that can be produced this way is similarly limited as on Windows, although in true Mac fashion, the implementation is much more intuitive.
Alt codes provide a way to output various characters in a way that is mostly independent of the current OS keymap, but they're OS-specific, and they don't work in every environment. For example, let's say that your hard drive is encrypted and you have to type a password before the OS boots up. Depending on your OS, Alt codes may not be available at this point. On Linux, they also can't be used in terminals outside of the X server, so you can't rely on them in every environment.
Alt codes on the UHK
Given that Alt codes are sequences of keystrokes, they're ideally suited to be assigned to keys using UHK macros. For example, you can bind the Alt code of "é" to Mod+e. UHK macros very handy, since they're saved to the on-board memory of your UHK, and always availblable without running special software once you set them up via Agent. I'm about to elaborate on implementing Alt codes on your UHK.
The macro editor of Agent is very intuitive to use, and based on the above one should be able to create macros that implement Alt codes. There are some gotchas, though.
First up, Alt codes are OS-specific which will pose a problem if you use multiple OSes. If so, you'll have to create all your Alt code macros for every OS you use, and then create OS-specific keymaps in Agent and bind the macros of the respective OSes. This is clearly laborous, but there's no way around it. We won't implement USB fingerprinting in the UHK firmware to detect OSes because it's fundamentally unreliable.
The second gotcha is that you won't be able to compose Alt codes with modifiers. Imagine holding Shift, then typing Alt code key sequences, then releasing Shift. Modifiers clearly mess with Alt codes.
Third, some Alt codes are dependent on the state of your OS. You have to have NumLock enabled for Windows Alt codes, and Mac accent codes are dependent on the OS keymap in use.
Accented characters in Agent
Some of you were wondering why Agent doesn't offer or display accented characters. This is one of those features that seem like a no-brainer from a user perspective, but in practice, it's not only incredibly hard to implement, but cannot be implemented properly. Let me tell you why.
In order for Agent to expose accented characters, it must be aware of the current OS keymap. Being a cross-platform application, it'd have to query the actual keymap on Linux, Mac and Windows. A quick search reveals ways to query this information (often rather obscure ways) via OS-specific APIs, but I have found no way to query the actual mappings between scancodes and characters which is critical.
Without the exact, per-key mappings, Agent would have to have a database of every single OS-specific layout, such as "French (Bepo, eronomic, 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 semicolon. Users should actually understand how things work when it comes to this topic.
That's it, folks! If you're still reading, then you're truly one of the brave few. Any questions, feel free to shoot them in the comments.