ok, so I dedicated last days days to refresh my UHK v2 usage because I keep considering that some of the modules really makes the whole device a good device overall.
This was my 2nd return, even added extra $$$ for new switches that boosted the whole experience in a positive way.
My keyboard background: Moonlander, UHK, some QMK and many ZMK builds (own built or purchased).
Now its time to put the whole thing in the box.
Positive aspects:
Hardware remains top notch. Solid, compact, well built.
Modules are the strongest point of this keyboard.
Macros are improving the experience.
Negatives
Firmware is the weakest point of this keyboard. It seem a very solid MVP, but no more. It does satisfy probably everyone that is comming from a non-custom firmware keyboard Many would disagree with me but just asking them to look around and then decide.
99% of macro examples are theoretical and there is no real page to explain in plain usage perspective neither the syntax neither the usage.
While hacking term is widely used around the product, the firmware has nothing to do with the term, seems the opposite. In fact a skilled user had to create the macro engine so that the firmware could raise to some expandable potential. If one wants to do something needs to spend quite some time to read and trial&error around the macro engine. This is not the way as an end-user.
In parallel, with the moonlander i never asked help support as everything was right there out of the box. With ZMK preety much the same, all things explained in the firmware page.
I have not lost hope, keeping the thing in the box.
You are basically complaining about ease of use due lack of documentation. I agree to some extent. But when you have found the way to the forum you find likely examples of what you want to do or just can ask and have a good chance to be helped.
Sure it would be nicer when a bit more advanced configurations could be done with Agent. But the plus point is that there is progress. You can not say for all commercial keyboards.
That a UHK user started the cool macro language is true, but is that bad? What matters IMO is that it was adopted and is in active development.
I thought the modules would be the killer feature and personally find that this is not the most important aspect of the keyboard for me, although a nice plus. My biggest complaint is the standard staggered layout. I guess a symmetric stagger (Katana like) could be the best compromise in terms of ease of transition, ergonomic/ comfortable hand position and compact keyboard. But it seems no company is going in that direction.
Quite the opposite. Karel does a fantastic job. I also understand the way things are explained. But I see ONLY himā¦ I hope you understand what I am saying.
Iāve been chatting with Karel long before this forum existed.
The right left modules are the most powerful. Key cluster, mehā¦ but still usable to some extent.
It canāt be katana style due to left side stager against the natural way of moving of the fingers. Alice layout started to have some attraction though.
Probably remaining on moonlander due to its unmatched wing like wrest mechanism. Working to do somethign similar for my Corne and Kyria and future Sofle.
Can you give some examples of what you were missing to do with the firmware? Overall I think it is very capable already and covers many use cases, although I can think of some better capabilities for home-row mods.
Yes, I understand that only one person is (the main or single?) developer. But that is the case in many smaller companies. It is also open source, so at least someone else could pick up. Surely it would be great, when there would be one or two more.
I use the trackpoint and removed the keycluster, not still decided yet if I want to use it. Attaching and removing it from time to time. Main reason is the stagger, because with the keycluster the two parts are farther away and then the top left row gets a bit more uncomfortable to reach, even it is just a difference of one or two centimeter in the position of the keyboard. I can live fine with the standard stagger, but guess a Katana60 style would be perfect. I can imagine it might be more comfortable than columnar layouts, but did not have a chance to test it. I see there is also a large standard stagger Katana keyboard, that was not what I was talking about.
Interesting you favor the moonlander overall. I guess most people type with some sort of resting like a wrist rest, table in front of the keyboard, arm rests of the chair or resting the arm on the front / corner of the table. I type with floating hands and think wrist rests can be bad (depending how you use them and how much you type), while typing with floating hands will not lead to any problems I assume. At least not, when you have the keyboard close enough ā closer than most people put it.
I think besides improving home-row mods, the other part which still is a bit missing is easy access to superkeys via Agent ā but that is not a firmware feature missing of course. I think with the current options of the smart macros the UHK is a great package which hits many good points and IMO superior in that regard to all other options I know ā allowing super fine grained custom configuration. But I also think the documentation could be improved much by examples of some common use cases. I think the configurations section in the forum could be a good place to start collecting those as well, not only full-fledged complete keyboard configs.
For example I liked the sticky AltGr / Shift macro recently posted. That is something which can be useful for many. Another example is the one-press macro I use to enter the mouse layer, instead of double-tapping, but still allowing hold-down use of the layer (and then returning to base automatically). I do no know if configurations like that can be easily done with QMK or in Oryx?
well, my first pause from UHK was complete lack of HRM. I was thrilled when saw the āadvancedā settings that allow better control for this. To some extent it does work well.
Since then I went to 42/50 sizes keyboards and found solutions like combos or behavioural mods to suit my needs, which worked perfectly in zmk or in qmk, yet i spent time mainly on zmk configs. There is now even a configurator that does a fantastic job in creating the config. So I got used to use less keyboard buttons for the same activities. I can achieve the exact global behavior regardless qmk/zmk/kmk. Apparently with this one i canāt do it without either relearning everything or giving up to combos or non binding macros, which honestly are non negociable in my view. Btw, can I set a key as transparent in UHK?
As i said, for those that come from a regular non-configurable keyboard, firmware may seem complete. Knowing that other firmwares exist that have what i need for years I canāt swallow what is being tagged in this forum as niche features.
Another point: If many macros are used, the agent becomes useless. Iāve seen some UHKs heavily macro-ed but in my eyes this is not a nice view in the uhk macro and the work is very cumbersome. I prefer to stay on an editor and work on the config directly.
In UHK I love how some parameters can be changed with the macro engine, for example the autoShiftDelay which can be adjusted on the fly to find the sweet spot or turn it off. Honestly not sure if this can be done in any qmk/zmk setup. Oryx has something for some special features. But that is pretty much it.
I think I qualify as one of the guys that tries to use the UHK to its full potential, and push beyond into the niche features range.
Yes, I am experimenting with home-row mods. Iāve found that the implementation in Kanata functions a good deal better compared to the advanced secondary mode on the UHK. The two things you can do better with Kanata are:
It allows configuration to enable short-timed mods only with keys from the other hand, thus minimising problems with quick finger rolls; but at the same time allow same-hand mods if the mod key is held long enough.
While typing very quickly, mods can be disabled until a short pause in the stream of key presses is detected, thus eliminating spurious false mods. It takes a bit of clever configuration to do this, but I think it is a really useful setting. This is achieved in Kanata by switching to a base layer without home-row mods as soon as one of the home-row mod keys triggers as primary. At the same time, it starts a timer which re-enables home-row mods after no key has been pressed for a (short) while (~20-25ms).
I donāt know how any of these two functionalities could be achieved with the current capabilities of the UHK macro language. Or it would require really a lot of complicated macro code.
I am not sure what these features do, or what you mean with these terms; I am not very familiar with qmk or zmk.
I mean, I think I understand combos, and they can be done with the UHK, although a bit cumbersome to configure if you want to trigger them in any order of key down events. (Different macros using ifShortcut need to be bound to all keys that can start a chord with the following keys in order.)
With transparent keys, do you mean the ability to leave keys on a layer blank, so that this key just triggers whatever the underlying (base) layer does? This is only available on the Control, Shift and Alt layers on the UHK, but not on the Mod, Mouse, or Fn* layers. I donāt see the use case though, because why would you shift to a layer holding a layer key and then just press another key to achieve the same as if you had not pressed the layer key at all? For Control, Shift and Alt it makes more sense, because you would be overriding the normal modifier function, but fall back to the regular modifier action when it is ātransparentā on the corresponding modifier layer.
And what are behavioural mods and non-binding macros? May I ask you to elaborate?
Iād like to understand in more detail what you see missing, and perhaps gather new ideas what I want to try, either in Kanata or in UHK macors.
The whole idea of a keyboard firmware is to make it work atomically without any other interraction. Using a sw like karbiner/kanata/kmonadā¦ one might as well buy the cheapest good keyb and use it conjuncture with any of the above swā¦ imho.
Right with the HRM. Having another keymap just for that ads more cluttering. For example I use both mac and win. I just need and extra layer to override 2 positions for example, while the Shift is already fixed in a superior layer. Indeed I reckon this can be made via a reversal macro (debatable if bind or not bind, indeed).
Example here. Combos are a good way for having more options without reaching too much the outer keys of the keyb, like num/func rows, especially within a hrm configuration where the aim is to limit finger and writst movements. There are more to combos than I say here (tri-layer, classic macro,ā¦ etc) all that available as a virtual layer available all the time, conditional or undonditional, depending on the options the user is setting.
True. I am trying Kanata to see what others have done to make HRM work better, and Iād like to see the UHK perform at least equally as well.
I can use Kanata on my Windows (work) and Linux (personal) Laptops, but not on my Chromebook. Thatās why I want the same functionality on the UHK.
At the same time, I also need Kanata (where I can install it) as sometimes I just use my laptops without any external keyboard; and I want to be able to use most of my keyboard muscle memory there as well.
Ah yes, for only those two keys you can dynamically rebind them with a UHK macro. Instead of binding keys to switch keymaps, you can bind a macro to reconfigure the two keys. Thus, only 1 keymap needed (plus macro).
Yes, I get combos. The UHK could be better at enabling easier combo configuration. Thereās this whole discussion about a āfloating layerā, i.e. recognising combos without binding them to a particular layer or a particular starting key. I think thatās really the way to go. Some stuff has to be checked before regular layer processing. Currently, the UHK cannot do that.
Iāve skimmed this, and I believe practically all of the behaviours map to some UHK actions, either directly, or more complex scenarios can be achieved with macros.
This kind of confirms what I had been thinking. There are two areas where UHK could be improved (the rest is already possible):
Tapping-term could be added here. Yes, advanced settings solves some of the issues, yet, the way this work in uhk is very different from any of my qmk/zmk. Iāve done some to side comparisons of the same things, where I had the possibility.
Interestingly enough, the āfloatingā layer on moonlander is contained within the each layer. Does adds some complexity, but also makes extensibility much more vast. On zmk this is configurable to whatever layer users wants, or can be available as a true floating, to all layers.
Another thing that should be added is behaviors as characters.
Now, that I keep seeing thing around the Macros, guys, my opinion is that to some extent this does break Agent UX. This should satisfy every type of user, and Iāve seen here mostly the light type, that does not even understand the basics. Agent should keep the ux simple and understandable at any time. Now, using it in conjuncture with the macro name its just ā¦ crap. If a macro is bind to a key, it should extract what that macro does and encapsulate the actions, not the name. Or maybe a short name to be added on macro definition.
ā¦ apologies if I get carried away.
I see; there are options, more options, and many more optionsā¦
I donāt understand what you mean with āas charactersā.
This is a very valid point.
I donāt think automatic extraction from just the macro commands would work. The intention of the macro needs to be described separately.
I try to name my macros to indicate what they are doing, like for example mute-unmute. When I bind them in Agent, that name will show up on the key, giving an indication on what that key will do.
I can see that it would be great to encode some description (help text) and maybe a short pop-up name within a macro itself, which Agent could use in the UI to display more information about what a key will do (when the macro is bound to it). There could be a library of macros, the āUHK macro shopā where you can download macros, and their descriptions would explain what they do. You download them and they get added to your configuration. You bind them onto keys, and Agent will be able to incorporate the help text in the UI.
Something like java or python inline doc but for UHK macros.
Example:
#--!-- Mute/unmute
#--!-- Tap to mute or unmute your microphone in MS teams. Hold to push-to-talk.
ifSecondary final holdKey LC-space
tapKey LCLS-m
When bound to a key, Agent would label the key as āMute/unmuteā, and when hovering over the button would display the description āTap to mute or unmute your microphone in MS teams. Hold to push-to-talk.ā.
no, its what we have as minimum duration for a tap or a hold. But implementation in uhk is/was different as i was told, in comparison to others. Maybe something was aligned through advanced configuration, but not sure. There is tapping-term-ms, quick-tap-ms and the crucial for hrm: require-prior-idle-ms which would disable the hold-tap when typing quickly.
well, not as characters per say, but as key-press behavior. At the lowest level a key-press is nothing but a manipulation to send a key-code to the computer, right? A behavior is nothing more then a sequence of actions orchestrated by the firmware to achieve the same thing, but maybe in a more complex manner.
For example:
Yes, that would be lovely. Or as a 1st phase a library in the demo of the agent. But you know, this must not be managed by the users.
Interesting is that 2 users are discussing probably niche things considered by the creator, things which probably wonāt even reach the thinking table, because millions of comments have been analyzed and almost none of them referred to the firmware, but the hardware. Well, yeah, coz people expect things to be either aligned in most majority either possible to do. In any case i dream of that day.
A macro shop or macro templates make a lot of sense to me. It could feature a nice UI to specify relevant parameters in a user-friendly way. We could allow user submissions, but itād probably be worth curating them so only useful and well-written ones would appear when searching for them. Feel free to open a separate topic to discuss this further.
