hello dears,
is there a way to create various combos so that the user could limit the usage of pinkies but still have the necessary symbols available? for example 2+w to create @… and so on.
I’ve been using them with zmk quite extensively on the Corne and also on Moonlander.
here are some references:
ZMK Combos
QMK Combos
See ifShortcut and ifGesture in firmware/doc-dev/reference-manual.md at master · UltimateHackingKeyboard/firmware · GitHub.
I am not user if it does exactly the same thing as the QMK combos, as the link doesn’t describe its internal function.
do they need to be in their own macro, then bind the macro to one of the keys?
or
they can simply each line can be added to $onInit macro as a global floating layer or $onKeymapChange to keep it contextual to a keymap.
Idea is that I am looking to do have them into one single block/section/macro that is not bind to any key, and not having tens of little macros then asign them to the various keys. This should be independent of any setup present for the involved keys, which may have their own macros or mods assigned.
ZMK and QMK are using positional id from the key matrix, not the key_ids as they are being seen on uhk firmware.
I am afraid they need to be in their own macro bound on the first key of the combo.
You may be able to do some amount of magic with layers, secondary-roles and rebinding things, but I wouldn’t advise that.
ZMK and QMK are using positional id from the key matrix, not the key_ids as they are being seen on uhk firmware.
How is that different? Key ids are also just integers that describe physical location.
Darn, such a sad moment :)). Well, maybe in time some feature could be implemented to have similar feature as in qmk/zmk. For those looking to limit finger moving, or those coming from ultra compact keyboards, these combos are critical.
For me is both since I use a Corne. All keyboards I have are matching similar principle for consistency usage.
nah, this is beyond my expertise, and not really in my aim to do for a keyboard. I do get that the api might offer some way, but doing it for 11 pairs of keys might not be that easy. firmware itself should be capable of offering this.
yes, you are correct, could be same. Though i don’t understand why they are like this, like y=14 and next letter u=7. There is some logic presume. 
Well, maybe in time some feature could be implemented to have similar feature as in qmk/zmk. For those looking to limit finger moving, or those coming from ultra compact keyboards, these combos are critical.
If there is a sufficient demand from users then maybe yes.
As of now:
- I don’t recall anyone ever asking for this, and I personally find it quite a niche request.
- due to the internal structure of the firmware, doing this generically is a bit difficult
- I had started digging into UHK because I was not satisfied with its feature set, but macros had gone a long way since then, and I find the feature set pretty satisfactory… Trying to implement every qmk feature never was my goal. Especially given that many QMK feature are custom-coded for that specific usecase. With UHK, my goal was much more to make the already-existing features reachable from the macro engine, and make them compose well from within macros. I.e., provide easy building blocks that could be combined to create more usecases. Maybe it is time that some other dissatisfied actually ported UHK to be QMK-compatible?
yes, you are correct, could be same. Though i don’t understand why they are like this, like y=14 and next letter u=7. There is some logic presume.
They correspond to the internal wiring. Yes, in hindsight, it was a mistake not to map them in a more intuitive fashion right in the beginning. Changing them now is complicated due to backward-compatibility reasons.
I am still somewhat confused by the “as a floating layer” part. Could you describe the mechanism in a bit more detail?
If the actions can be described using existing layers, the implementation may be much easier than a general table of totally custom combos.
Fully agree. Just for clarity, macro engine is doing a fantastic work, and i assume is not easy thing to have things run/standy while not being bind to a key, and act as a tigger.
Maybe something would be possible if various behaviors could be loaded from $onInit or $onKeymapChange into memory, yet as you said could be complicated and depends on request.
In sw development you know users do have implicit expectations or explicit ones. Usually implicit ones are hard to express and hard to be guessed by dev team.
The term Ultimate Hacking Keyboard, besides the name and the marketing perspective, does create several expectations, especially from the ones that come from qmk/zmk and tendency is to have a continuous experience rather than a limited one. Definitely, the power points of the keyboard are the modules primarily and the build quality of the board itself, but these should not replace a previous user experience and call it a compromise. It should extent and improve. … I hope you understand what I am saying :).
Just now something popped in my mind: How about some polls to ask the community about what the feature they would look to have or express their opinion? But that is more toward Laszlo to analyze.
I hope you understand what I am saying :).
Yeah, but at the same time… I am not the correct person for you to try to convince about this.
As for the amount of work done on the keyboard… just as much work as I had done on the actual macro engine, I had done on pushing Laszlo towards the idea of greater flexibility and customizability. With this work, I am satisfied too, and don’t think I should press it more. My current opinions may have been affected by cooperating with Laszlo, but they are that he has turned out to be either right or sort-of right in many things - e.g., when insisting on not cluttering things too much. As a result, currently our philosophical views are quite coherent and stable.
This is to say: If you want, you can take a stab at actively creating better (mainly coherent, compact and user-friendly) feature specifications and convincing us about their merits and importance, or at developing the firmware or at ensuring independent funds for the development. Otherwise, I am afraid you will have to satisfy yourself with what Laszlo wants this keyboard to be.
How about some polls to ask the community about what the feature they would look to have or express their opinion? But that is more toward Laszlo to analyze.
There were polls in the past, except targeted much more on hardware than software. The amount of feedback was staggering, but firmware capabilities weren’t requested all that much.
Also as people’s interests goes, note that the hardware-oriented polls got hundreds of responses, but whenever I try to consult the community about some niche QMK features, or smart macro future direction I get barelly a couple of answers.
I’ve read all the tens of thousands of customer messages we’ve ever received during our company’s lifetime, and I have a deep understanding of what provides value.
The problem with niche features is their very low return on investment. We not only have to develop them but also maintain them forever, making long-term development costlier than what we earn by having them. They also increase user-side complexity, even for users who never use them. Therefore, from a business and user standpoint, I’m confident that we should never implement the ~1% least requested features.
I understand that some who push hard about niche features dislike my policy. I don’t mean to discourage the proposal of new features; I just wanted to clarify our stance.
I agree that we should not strive for feature parity with QMK/ZMK. From a usability standpoint, smart macros are so much better than setting up a toolchain and writing C code. But it’d be useful to eventually have migration documentation.
2 Likes
Fair enough, to understand the creator’s perspective.
Since the issue has been so bluntly put then here are my two cents:
- yes, macro engine is the a good way of extending flexibility.
- yes, some niche features are maybe a pain, yet they may bring some more revenue with new clients. I have seen the reviews and some promoted ones and can’t say much about how hacky these are. Honestly presenting in a video a code that seem complex, saying it is a macro or some hack for QMK, when instead was the low level keymap which a user will never need to write anyway for qmk, while i’ve seen almost similar things on uhk firmware, that tells me the review is biased and false. If that is the review Laszlo wants to view to attract new clients, ofc its his prerogative.
- Macro usability by binding them to a key as it is now I find it rather spartan and breaks the experience of using the lovely agent. ZMK does this by wrapping all that then selecting it as an option into the character set.
- Possibility to add macro and execute them without binding them to a key in the agent would add more flexibility. STM chip is more than capable on doing that.
- This one depends on the targeted users. Yes, not all QMK/ZMK features worth having them yet these firmwares are somehow the gold standard of keyboard firmware, heck even KMK firmware is more extendable. Many features are implicitly expected, and ofc if majority of customers come from a standard keyboard, ofc they have no opinion of what features would be nice to implement.
- Timing events seem to need improvement and more comprehensive documentation to make them understandable. Needs countless adjustments if one wants home row mods(which by the way these have been out of owner policy for some time). While for some works for some really does not work and neither documentation can be found to understand better. I would assume this is a core feature.
- Personally i come from Moonlander, which has a fairly similar configuration experience, and custom qmk firmware makes it much more enjoyable to work with.
- I hope in some years i can return to the keyboard and feel i have not payed $$$$ and not using it because of a ‘policy’.
Now I’m considering puting all back in the box, we’ll see. Had some hopes…
What if we had one macro that gets executed on any key press, like $onKeyPress? Within that macro, find a way to express various shortcuts (combos) and generate anything that you wanted the “floating layer” to do. If caught within the macro, the output would be only what the macro generates. If not caught within the macro, regular layer processing of the UHK would continue.
Users with very niche wishes could then “script away” whatever behaviour they wanted…
2 Likes
Very interesting idea. I like it because of its general nature. Interested in @kareltucek’s opinion regarding its feasibility. (He’s on a long vacation, but I’m sure he’ll comment eventually.)
I have thought about it multiple times, but I am not comfortable with so many running macros.
Also it is irrelevant with respect to above issues. Parametrizable smart macros: brainstorm for future specification - #4 by kareltucek needs to be solved to allow such flexibility instead.
2 Likes
(Also, @mlac, please tag me in threads that need/“need” my reply.)
1 Like