I stated that I sometimes do not have NEO as my OS layout.
Ah, I see. Then tapKeySeq macros are indeed your best bet unless you prefer to do custom coding.
If there’s such a problem with the Unicode bindings, then why is there the tapKeySeq CS-u at all in the FW?
Well, the command is tapKeySeq, not tapKeySeq CS-u. There is nothing special about the CS-u - it simply means Control+Shift+u.
tapKeySeq is for triggering custom key sequences. It was not designed for altcodes specifically.
Please note that every OS needs a different tapKeySeq sequence.
My naive thought is that it would not be too much effort including it in the key configuration dialog.
Graphical UIs are Laszlo’s domain, but his reasoning would mention that this is a niche usecase that justifies neither the additional GUI clutter, nor coding time and resulting maintenance burden.
Furthermore, the fact that we would have to implement at least 3 different solutions (for different OSes) and further burden the user by manual host OS choice (as UHK doesn’t have that information from the host) doesn’t help. Yet more, implementing a special-case gui for this specific usecase would solve only this one special case, while it would leave a number of other similar issues unsolved.
This leads me to a more general problem of how to parametrize macros. I would love to add a way to easily parametrize macros, but in order to do that, we have to figure out a reasonable way how to expose that feature to the user. For that, I had already tried to kickstart a discussion at Parametrizable smart macros: brainstorm for future specification .
We didn’t move very far, which I among other things take as a lack of interest from the community.
Of course you are welcome to participate in the discussion, or to try to change Laszlo’s mind.
Your trackball solution requires activating the mouse layer?
No. The setup works directly in the base layer.
The solution triggers mouse layer only to faciliate rocking gestures, browser shortcuts and the scrolling navigation mode. (Your original suggestion (additional buttons above the trackball) suffers exactly the same limitations regarding the scroll navigation mode. Feel free to open that topic as well in case that (navigation modes being coupled to layer activations) is what you are complaining about.)
Of course you are welcome to bind stuff however you like.