That is the ideal, which unfortunately will not happen as long the keyboard integration in the different OS are not changed and synchronized.
When that works for you that is great. No need to change it then. BTW, you can also have a look at other options and partially implement them as you seem it fit to your needs and wishes or can improve on your current solution. The UHK is a great keyboard to allow you to relatively easy try out out different ideas and concepts. You can stay as close to a standard keyboard as you want, but on the other side get creative and implement almost everything which you can think of.
One of OP’s very points would be solved by this - we need to send different altcodes in different OSes. Only exposing it as a variable would be enough.
You seem to have thought (and written) on the subject a lot, so can’t help but pick your brain. I need a handful of umlauts that I currently handle via unicode sequences sent via a UHK macro.
How would you do it? Still use unicode or some other solution?
Like Max said, without further information one can not give a meaningful answer and there is no one-solution which works all times possible unfortunately.
In general, the more you can do on system level the less likely to get unwanted effects or behavior. But even when you use a custom layout in the OS you can stumble in situations where it will not work as expected. But not too often luckily and also nothing which can not be fixed / worked around in some way.
It is hard to get it right. That was discussed before and there are options, but they are AFAIRemember not 100 % waterproof. If it is worth the efforts? Would be surely nice. IMO other features are way more important and helpful. Being able to choose the system layout in Agent being one of them. Implementing “all” tap-dance options and make them easily accessible being another one.
But to your question. What works now and is a very good solution already is to define different setups. You will likely not switch between OSes every few seconds. So you can just switch the UHK configuration with a quick keypress (Fn - … whatever you defined).
In my UHK I have several configs, even for the same OS, depending on the layout chosen in the OS and if I run additional software (Kanata) to rebind keys. The latter I do in the cases where I quickly need to switch between external and laptop keyboard. At work I just unplug the laptop from the docking station and continue to type without needing to make any changes. So in that case I use the external keyboard as a (mostly) dumb keyboard and largely mimicking a standard keyboard.
To clarify, reliably implementing OS fingerprinting on the firmware level via USB is not possible. However, Agent or a script could switch to the desired OS-specific keymap or execute the desired macro commands.
Which basically means it is not possible (from the keyboard itself – which was the request). Then there is not much difference to use another software option to handle the OS specific stuff. I am just thinking if there is still an advantage to use the UHK instead of a software solution – and in some cases there is. But I still wonder if the benefit will be that large, when you now can already switch to another keymap on the UHK with just one keystroke already. Is there a real use case where it does make a differenc? Not to say it wouldn’t be nice of course.
Apart from OS detection, one thing that makes sending unicode characters hard on the UHK at the moment is the need for separate macros for each unicode character. For example, it you wanted to create a Greek character layer (like one of the layers of Neo), you would need 26 macros just for all Greek characters of the alphabet - for one OS. Multiply that if you need different macros for another OS. (I am assuming you create one keymap per OS, and user manually switches between them.)
Parametrised macros may be a solution for this. You would bind something like “Macro: send_windows_unicode” with “Macro parameter 1: 00a1” to a key. For different keys, it would always map to the same macro, but different hex code parameter. In the macro, you’d need to be able to do tapKeySeq CS-u $param.1 enter.
Karel, I was sceptical, but tried a small portion of your mouse click solution. Works for me, much better than I expected. So I want to say “thank you!” You really helped me.
Just wanted to chime in: UHK 60 keyrest could be just a bit longer - maybe 0.5".
I’m going to use something - superglue, epoxy, bubblegum, don’t know (suggestions anyone?) - to add a tiny bump to the F & J keys. I’m frequently putting my right hand with index finger on K not J and typing a bit before I notice.
Yes, but the bottom row uses Kailh Choc V2 sockets, and there’s only a handful of Choc V2 compatible switches out there right now. (I’m using the Kailh/Lofree Wizards in mine ATM):
The UHK shop only has three Choc types (Brown tactile, Blue clicky, & Red linear), and I think they match them to the main switches by type (tactile, clicky, & linear). Since the silent pinks are a linear type, I’m pretty sure you’ll be getting the Choc Reds.
Just trying to see whether 