Yes, but KM should do nothing, but wait until one of the apps listed in the macro is the front app. And that can only be the case when the AltTab window is closed.
Did you replace ⌘tab with ⌘9 in the AltTab settings?
Right, but you're still triggering the macro potentially many times over, which isn't ideal.
Yes. Part of the issue, as mentioned, is that AltTab doesn't seem to be recognizing that the keyboard shortcut has been released, so it doesn't bring the selected window into focus.
Nice idea, @Frankb, but unfortunately this solution is not reliable on my machine, sometimes it works, sometimes it bugs - especially on quick presses - where I have a pane of alt-tab windows stucked at open state, but if I press and hold alt, then seems to be ok, I do get all other windows of an app to the front as well (and then KM engine gets high CPU use, maybe it's stuck in some loop)
Thank you @esv. The idea may be nice, but my execution is terrible.
The question remains, why does it work for me but not for others?
Could this have something to do with the settings in AltTab?
Have you tried putting a pause here and there? Surprisingly, it only works for me when I have this pause of 0.5 sec. It took me a while to figure that out.
yes, added a pause after the first step, increased the pause to 1 sec and a couple of other combos (but nothing exhaustive)
have you tried a sequence of immediate switches? When you tap once and quickly release, like when you're trying to switch between two apps below the apparition delay threshold? Or do that twice to go back and forth, something bugs in this area, have also encountered a similar issue when was trying to use Karabiner to trigger Alt-tab for some tricks, it's just unfortunately not very composable
It all works perfectly, whether I do it fast or slow. First the selected window of an app appears and with a slight delay all the others. But when I do this quickly, the AltTab window does not appear at all. But it still works.
Yes, that's the one I've tried precisely because I didn't want to get into more same-shortcut bugs
yeah, this part always works, once KM takes over and sees the window, the next step is done fine
The main bug is when AltTab doesn't get release event on fast switches, so its window always appears even if I release before apparition delay (and I've disabled Karabiner/BTT to try to avoid interference)
indeed
Version 6.61.0
But I think I've found an easier way to bug KM:
hold ⌘ and
press & hold (or tap and then press&hold) ⭾
then KM gets to a high CPU %
so it doesn't seem like AltTab misses the release event, but rather KM not producing them properly (or maybe there should be a more advanced input simulation rule)
By the way, for the folks in this thread who would like to see AltTab add this option natively, feel free to chime in here on Discord, which the developer will see...
Looks too simple to me reading this lenthy thread, but it seems to do what you describe...? If you don't want this to happen as soon as you click on any other app's window, maybe this variation might help:
It's an interesting idea! I worry that it would trigger bringing windows to the front in instances where this isn't desired, but I think it's worth a shot. Thanks, @Waldbaer.
Yes, this might become a problem. If the "If key 'tab' down" solution does not work, you might try to use another macro (2) triggering whenever "AltTab activates" (comes in front) and activates the simple Macro I suggested above (1) (which would be deactivated normally). You could activate it for a period of time or build a third Macro deactivating the first after triggered by "AltTab deactivates" (maybe after a short wait to make sure it fired). Good luck!
Nope, but this gave me an inspiration to just ignore AltTab completely and I think the example below works with an extra condition and a cancellation timeout:
let KM sleep when the key is triggered and wait for your apps to come to the foreground,
then AltTab does whatever it does without any interference from KM,
and then if you activate the needed Apps (either by AltTab or via any other method, with a 5 second timeout to avoid sleepers waking up when you don't expect)
KM does its magic and brings all windows to the foreground!
No more stuck windows! And conceptually this seems a bit cleaner as it doesn't try to control other apps?
(Haven't tested this much yet, had high CPU , but that might've been a holdover from the previous macro or maybe sleepers not being cancelled?)
Another idea: is it possible to detect when AltTab's window switcher window appears/disappears? I tried Window conditions, but those don't seem to catch the switcher (I guess it's a special kind of window?)
The menu condition is unfortunately not reliable (does KM try to parse all the menu items? as that might be slow with many items)
It's not a solution with KM, but John Siracusa made an app specifically for this. It's called Front and Center. It enables you to switch the window behaviour on app activation.