I stumbled over what I would call a bug or at least unexpected behavior.
I have my ‘LeftShift’ key defined as the letter ‘K’, but as the secondary role to behave as shift. This works in principle – for typing words with k or K and also using the left shift key to enable shift when I type a letter on the right hand side.
But it does not work in combination with “mouse combos”! When I want to select multiple items with the mouse holding Shift is the shortcut needed to do this. But this will not work and basically making this option not useable for me in that scenario.
Similar I have the Shift-key with MOD as the secondary role. To be able to still get autorepeating Shifts I defined one key as Shift in the MOD-layer. But when I hold (Base-Layer) Shift to activate the MOD function and press the key defined as Shift in the MOD-layer the autorepeating of the Shift is not triggered.
I only tried an external mouse, but that should not matter. When I use a standard keyboard I can select an item (for example in explorer) with the mouse. Then hold-Shift and select another item. All items in between will also be selected. This does not work when secondary role is used with the UHK.
Most keys will autorepeat when they are hold down. Characters, Space, Backspace and more will trigger repeated output/ action.
I just see that I accidently wrote “Shift” does not autorepeat. What I described under 2) should read “Space” – unfortunately I can not edit the post any longer. Would be really great when the time span could be increased!
So the correct error description is:
Similar I have the Space-key with MOD as the secondary role. To be able to still get autorepeating Space I defined one key as Space in the MOD-layer. But when I hold (from the base-Layer) Space to activate the MOD function and press the key defined as Space in the MOD-layer the autorepeating of Space is not triggered.
The secondary role only kicks in upon chording. If you hold a single key, the secondary role isn’t triggered, and it’s not considered a combo.
The UHK is unaware of other USB devices, such as your mouse, so from its standpoint, you only press the left shift key for a certain time. It’s unclear when you expect the left shift key to output ‘K’. When the hold time of the key is smaller or larger than a certain interval?
This is a similar case, except you probably don’t want Space to kick in as soon as you press the key but after a certain interval.
The above should be achieved with smart macros, but I need the details.
Sure UHK is not aware of the mouse, but it needs to output a Shift on SeondaryRole, when this is defined as such. This is not the case, in combination with a mouse action.
Steps to reproduce:
in Explorer mark a file in a list
hold the Shift-key
click with the left mouse button on a file which is a few places away in the list. Expected result: The first file is still marked, as the last one which was clicked on and all the files in the list in between the files are marked as well.
K + SecondaryAction: LeftShift → does not work.
The following macro works as it should, meaning it will also work with mouse shortcuts like outlined above
:
resolveSecondary 150 primaryaction secondaryaction
primaryaction: final tapKey k
secondaryaction: final holdKey leftShift
Yes, that is possibly the same problem. A (character) key which supports autorepeating (under Windows) should trigger multiple characters, when the key is hold down for a longer time than specified in the Windows settings (character repeat rate of 0…3 equaling 250 ms to 1000 ms, with the default of 500 ms).
When I have a space-key with SecondaryRole = mod, of course this autorepeat will not work any longer for this space key. That is expected. But when I assign “space” to a free key in the mod-layer I should be able to trigger autorepeated spaces in that way (holdKey space to trigger mod + hold key which has space in the mod layer assigned to it).This does also not work and seems like a bug or at least unexpected behavior to me. Space must always auto-repeat after the defined (OS) time span, when this is defined else (tapKey!).
Based on my previous post, secondary roles are not working according to your expectations, but rather, they kick in upon chording. There’s a difference between something that is not working versus not working the way you expect it to work. I wanted to clarify that I don’t consider the current behavior buggy.
We can change default behavior when justified, but there are many users with different needs, so we may end up breaking someone’s configuration in the name of doing the Right Thing. Luckily, smart macros are here to the rescue, and based on your My keymaps in progress (qwerty/qwertz based) post, you may have figured out everything.
I couldn’t reproduce your second use case:
First key is mapped to primary role: Space, secondary role: Mod.
Second key is mapped to primary role: Space, secondary role: none.
Holding the first key, then holding the second key autorepeats Space.
Thanks for the answer. Not that important if it is called bug or unexpected behavior. From a user point of view one will expect that when a key should act as “Shift” it will do so in all situations like a regular shift. This is not the case with the default secondary role, luckily it works with the smart macro. If changing the defaults would break something I can not estimate.
That is strange. I just retried it, exactly like you describe, but I do not get the autorepeat kicking in. Both when I use the standard SecondaryRole (like your steps outline) and also not when using the macro:
resolveSecondary 200 primaryaction secondaryaction
primaryaction: final tapKey space
secondaryaction: final holdLayer mod
I have not found a workaround so far. What you see in the screenshot is the placeholder for a working solution and was just left there when I tested some macros to hopefully get the space-autorepeat functionality. But I did not succeed
BTW, there is an interesting difference between the macro for space-mod and using SecondaryRole for space-mod. With the macro I see the “mod” LED light up, while with the SecondaryRole this is not the case, which I found puzzling, because in both cases the “mod” layer will be active on hold.
If you use the standard primary/secondary actions in Agent, the light will not come on until you press the second key (while holding the first). The standard logic is:
When key is pressed down, don’t do anything.
Next, one of two things can happen:
a. A second key is now pressed, activating the secondary action. This is when the light comes on because now the layer is actually switched on. The layer will stay on until you let go of the key.
b. You let go of the first key without pressing a second one, activating the primary action.
Because the UHK does not see your mouse click on an independent mouse, it will not switch to your layer because it is still waiting to determine whether you want primary or secondary action. Thus, if your secondary action on this key is “Shift”, then Shift will not be active when you click your mouse.
With the macro version and resolveSecondary, the secondary action will - in addition to the above options - also activate after the timeout expires. This should allow you to Shift-click, provided you wait long enough after the keydown so that the secondary action (holdLayer) becomes active.
Thanks for the great explanation. Now I understand. So indeed the current SecondaryAction approach can also make sense in some use cases. From a newcomer standpoint I think the macro version is more to the expectation of most users – at least for me, but I can not speak for everybody of course
@rpnfan If you share your exported configuration, I’ll try to reproduce your second use case with it. I’ll also try to come up with a smart macro that suits your needs.
The macro version using resolveSecondary uses timers, so it’s dependent on the typing speed and quality of the user. The standard version is very clear and simple, and hopefully easy to understand. That’s why I think the standard version is suitable for new users. The logic is simple: tap the key on its own, and you get primary action; hold the key and tap another, you get secondary action (another layer).
To standardise a more complex behaviour with timers one would need to agree what timing would be suitable for at least 90% of users.
Thanks a lot for the offer. Very much appreciated.
Mmh, I understand your reasonings. My point of view is a bit different in that I think it is more surprising to a user when a function will not kick in when the definition says it would do say (in the example: no Shift active although the key is hold). It makes total sense to have the default SecondaryRole behavior for some use cases, but I think as the default the macro version would be more in line with the expectations of the average user. Best is to offer both options and explain in the (somewhat advanced) manual when to use which version. I am happy that UHK supports both strategies. I am very satisfied with the UHK and what I can do with it, the smart macro options are a real game-changer IMO. A great option for advanced users, but also a good way to have an intermediate solution till the default configuration is extended somewhat more (super keys / tap dance for example).
I thought about that already. I think 500 ms would be a good time, which is pretty long and similar to the default time of Windows before autorepeat on a key starts.
The space not repeating problem is solved. I just double checked on another computer and there it worked fine. After further investigation on my main computer I found that I accidentally had still a keyboard tool running. :-/ Stupid mistake… Sorry about my wrong “bug report”!
