Or it would allow me to easily set a keyboard shortcut to not run if I'm holding down another key (I have Ctrl+Option+Left, Ctrl+Option+Up, and I want to add a keyboard sequence that triggers Ctrl+Option+Left+Up that does something different; but currently it seems I can't easily prevent the standard shortcuts I configured from running; except to tell them to not run if another shortcut has run within Xsec, or not run if a certain UUID has recently run, etc (which isn't user-friendly in the UI)
Keyboard shortcuts only trigger if the specified keys are pressed. Any additional modifier keys would lead to that shortcut not triggering. Or did I misunderstand something? How would your example be possible when the conditions would allow to check for keys/modifiers?
Firstly, it would have been ideal if I didn't have to record the Ctrl+Option as part of the key sequence, as I don't want to have to press them in the specified order; I just care that those modifiers are currently active. It would have been much better if I could have used the standard 'Trigger only while holding these keys' sort of functionality that is available to other trigger types:
But since that wasn't possible, I figured maybe I could check if Ctrl+Option were active from the advanced conditions; but it seems that we aren't able to use keyboard / modifier keys in the advanced conditions on triggers at all:
That's my first use case, but it's something I can work around in the meantime by just having the Ctrl+Option recorded in the sequence, and ensuring I press them in the perfectly correct order every time.
So now that I have the 2 keyboard shorcuts + the 1 key sequence set up, when I try and press the key sequence, all 3 of them activate:
If I was able to use keyboard modifiers/etc in the 'advanced conditions' of the 'Keyboard Shortcuts'; then I would be able to do something like configuring Ctrl+Option+Top to not run when the Left key is being pressed, or similar.
RE: Layers, I think his goal was to basically change how the keyboard works in general while capslock was enabled (I might be wrong, that was my assumption). So that when in 'capslock trigger mode', certain keys can be set to trigger a function on it's own. Eg. W (with no other keys pressed) would map to Up, etc. That's why I suggested (on the other thread) creating a new preset and enabling/disabling it when caps lock is toggled.
@Frank1 I definitely use a lot of key combos/modifiers, but it's less about 'running out' of them and more about mapping them to what feels logical for my brain. I have use cases where I want the window at the top of the screen, others left, others bottom right, others top right, etc; and while I could assign it to arbitrary other keys, what makes the most sense to my brain (and thus the easiest to remember without learning cryptic shortcuts) is to use the arrow keys.
That said.. that is a SUPER useful technique to keep in mind! Just because it isn't super clear to me at the moment, how would you go about setting up the 'hold F + something else' to trigger a shortcut using the advanced conditions? And is that before the new currently_pressed_keyboard_keys changes mentioned above, or since they're implemented?
Makes sense, and I likely wouldn't end up using a normal letter like that (more likely to use a number or similar that I use less in normal typing), but am definitely curious as to how you achieve the 'turn anything into a modifier key' approach, regardless of which key I end up choosing to do it.
There are other ways to do this. For example, "4" you can toggle a Stream Deck Emulator Window (instead of moving your mouse to the menu bar and back). This has the advantage that you can see the shortcuts if you don't know them by heart.
Ah ok, so essentially the position of the mouse being over the menubar or not is the thing that acts as the 'modifier active' state; which you manipulate based on the key (4) being held down?
Clever way to approach it! I wouldn't have even thought to use the mouse pointer position like that!
While I haven't tried it, I was thinking that I could also just set it up so that a 'normal' press would continue to type the key as normal, but a 'long' press/hold would then make it the 'modifier' key. I think that way the only functionality I would lose from the key is being able to hold it down for repeated keys (eg. 444444444)
Just tried it though, and it seems that even when the trigger is set up to have a minimum hold time, it still prevents the standard key from working in normal typed situations
I was thinking maybe I could just create a 2nd shortcut that triggers on a short press, as the link there suggests:
And playing around with it now.. that seems to work:
Created 2 triggers, one for the 'long press', one for the 'short press':
For the long press:
Prevent recursive triggers
Trigger on Key Down
Minimum time keys need to be pressed: 1sec
And then i'm just using a Hud Overlay for the test long-press action:
For the short press:
Prevent recursive triggers
Trigger on Key Up
Minimum hold time: 0sec
Maximum hold time: 0.99sec
For the short-press action, I'm basically just having it send through the same key as my trigger, so in this case, b:
So now, if I long-press b, then the hud overlay is shown:
And yet I can still type b normally, and it functions as though there was no long-press key assigned to it; at least for the most part. There seems to be the slightest bit of lag, so when I can type really fast, it ends up putting the b 1-character out of order. eg. When I am typing 'be' I can press the keys so fast that it ends up being 'eb' due to the lag. Very occasionally it also seems that it might end up doubling the letter, so I end up with 'bb' typed. So for that reason I would probably still choose not to assign it to a key I use super often in typing. But for the most part, it seems to work pretty well!
Something else I only just discovered (or maybe re-discovered), is that if I have multiple actions assigned to the same shortcut, then BetterTouchTool will show a little menu and let me choose which one I want to trigger. So for this test I just duplicated the long-press action and gave it a different description:
And now when I long-press it, I get the menu to choose which one I want to trigger:
I was also thinking that maybe we could use the 'assign value to variable' action to store the 'modifier active' state (rather than your method of moving the mouse onto the menu bar/back), but it seems that we can't read that from the 'trigger conditions' 'advanced conditions'
Edit: For this last use case, I just opened a new Feature Request:
Edit 2: So it seems that it's already possible to use custom variables in the advanced conditions!
We can use an action on the 'long-press' trigger to assign a value to a variable (eg. isBLongPressed):
And then read that variable in the 'advanced trigger conditions' of a different trigger:
We would also need to make sure to 'unset' our variable when the B key is released, so putting something like this in a 'key up' trigger:
I originally tried having 2 'short-press' shortcuts configured on 'key up', the first with the min/max hold time as shown in my previous message, and the second that had no max hold time; but having 2 shortcuts set up (even with the different hold times) resulted in the 'which one did you want to run' menu being shown.
I then tried just having the 'short-press' shortcut without min/max time on 'key up', which worked well, but resulted in an extra b being typed when using my long-press shortcut, which wasn't ideal.
I was thinking maybe I could be 'extra tricky' and configure a 3rd action so that I have:
Long-Press (key down, min hold 1 sec): set isBLongPressed = true
Short-Press 1 (key up, min hold 1 sec, no max hold): set isBLongPressed = false
Short-Press 2 (key up, no min hold, max hold 0.99sec): send B key and set isBLongPressed = false
My theory with this was that it should prevent the extra B being sent through on a long press, since the only way that the B is being 'typed' is by 'Short-Press 2', so if it's configured not to run when the key has been held for the 'long press time', then it shouldn't trigger. Though unfortunately in my testing, this was still triggering.. so it might be a timing issue (0.99sec being too close to 1sec), or it might just be a bug in BetterTouchTool; not sure.