Detect when AltTab is active

[eugenesvk]

I have a confict with AltTab for the convenient Alt+Q to move left in the window (to avoid inconvenient Shift) as I'm using Alt+Q in some apps via Karabiner-Elements

I'd like to resolve this conflict, but for this I'd need to be able to either:

• detect when AltTab's window is active
• run some kind of CLI/IPC command by AltTab to notify other apps that it's active

As far as I understand, AltTab is using some special window type, can this be detected somehow?

If not, can AltTab add an functionality to run some arbitrary cli command each time it's activated (then I could use it to set a variable in Karabiner as I do for some other apps)? (I think Karabiner doesn't support any other IPC)

Do you have a better idea :)?

[lwouis]

Hi,

You seem to use a quite specialized workflow which I'm not familiar with. I'm not sure I understand it. Could you please illustrate it with a video, and explain it a bit more?

In general, you can remap alt+tab to anything else. For instance command+tab. That way, maybe alt+Q doesn't conflict with AltTab anymore, since you would do command+Q to quit a app using AltTab. I'm not sure that's your scenario here. Just sharing in case it is.

Another thing is using the Blacklist in the preferences, you can ignore AltTab shortcut while certains apps are open. You may be able to list the apps using alt+Q there?

Regarding IPC, there is no such feature today. There is a ticket on that topic: https://github.com/lwouis/alt-tab-macos/issues/371, but nothing has come of it yet.

Thank you 🙇

[eugenesvk]

Sorry it wasn't clear, let me try again

I use 2 keybinds within AltTab to switch between windows (I'll use Cmd as an example to avoid ambiguity with the name, but whether it's Alt or Cmd doesn't matter, I use both for slightly different operations, so will get a conflict):

• Cmd+Tab to move to the next window
• Cmd+Q to move to the previous window (this is better than Cmd+Shift+Tab)

I don't use AltTab to quit any apps, only to switch between them, so there is no conflict here. Also, when AltTab is opened, it gains focus, so there is no conflict if I also use Cmd+Q to quit an app when this keybind is defined within that app, all is just fine

But then within some apps I use Cmd+Q,Cmd+Q (double tap) to quit an app (to avoid mistakes on single press for some important apps like a browser). This requires a keyboard remapping tool Karabiner Elements. But now KE overrides AltTab, so if I'm in a browser and

• press Cmd+Tab: (not bound in KE) this opens AltTab as expected
• press Cmd+Q: (bound in KE), but KE doesn't know that AltTab is active, it thinks a browser is active, so it "eats" the first Cmd+Q, thus I don't get a previous app switch

If only I could make KE aware of AltTab, then I could add some global variable logic to pass Cmd+Q to AltTab and AltTab will "eat" it and not pass it to the browser since it has focus over the browser

Another thing is using the Blacklist in the preferences, you can ignore AltTab shortcut while certains apps are open. You may be able to list the apps using alt+Q there?

I don't want to ignore AltTab, it's great :). But the issue is that AltTab isn't getting a keypress since Karabiner takes over. It's not the apps that use Alt+Q, it's the keyboard manager

Regarding IPC, there is no such feature today. There is a ticket on that topic: https://github.com/lwouis/alt-tab-macos/issues/371, but nothing has come of it yet.

This one seems different as I don't need to control AltTab via CLI, but the opposite — I need AltTab to control another app. So AltTab:

• on showing its app switcher would call Karabiner's cli binary with a few arguments to make Karabiner aware of that event.
• on hiding its app switcher would call Karabiner's cli binary again with a different set of arguments

This doesn't need the complicated separation of AltTab into a server+client etc.

[lwouis]

Thank you for clarifying. It's quite a an usual workflow indeed.

You may struggle to implement this. Window focus is quite convoluted. It would appear on the surface to be simple, but it has many complexities and historical crust. There is keyboard focus, mouse focus, focused window, and exceptions and tricks that the OS offers for common use-cases such as HUDs and popovers.

When AltTab is summoned, it brings its window on top. That window however doesn't really take focus. Notice how the top-left Active App is not AltTab, but the app that was focused before AltTab was summoned. Notice as well that if there was a keyboard focused input, it stays focused. We wouldn't want AltTab to mess with what the user was doing before summoning it.

Thus, it may be tricky to script KE to know that AltTab is "active". If you can look for windows, you can definitely check if its main window is open. It's a special window, but totally visible through the Accessiblity or CoreGraphics APIs.

I hope this helps. I'll close this ticket now, since there is nothing actionable for AltTab.

Thank you 🙇

[eugenesvk]

There is keyboard focus

Yes, this is the only one I need to know about!

That window however doesn't really take focus. Notice as well that if there was a keyboard focused input, it stays focused.

But for keyboard focus it does, all keyboard input is taken over by the App Switcher (if you press 1 when it's active, you don't get 1 typed in your text editor), which is the definition of keyboard focus.

We wouldn't want AltTab to mess with what the user was doing before summoning it.

Sure, but that happens automatically when any new window is closed - focus is restored to the previous focused window.

If you can look for windows, you can definitely check if its main window is open. It's a special window, but totally visible through the Accessiblity or CoreGraphics APIs.

Unfortunately KE doesn't support scripting, so it only checks for "normal" windows, not these special ones that don't become "active foreground windows"

By the way, does the act of showing AltTab App Switcher window generate any OS-wide events? If it did there could be some other utility that could track those events and filter AltTab and then maybe tell Karabiner?

there is nothing actionable for AltTab

Well, there is - executing a cli command on 2 events of gaining/losing keyboard focus

[lwouis]

Hi,

Sure, but that happens automatically when any new window is closed - focus is restored to the previous focused window.

AltTab doesn't take focus, then restore it. It doesn't take it in the first place. Some apps will react if the focus is lost. A video or game might pause for instance if they lose Focus. AltTab doesn't trigger that response since keyboard focus is still partially on the original window. You can see the blue focus ring around text input for instance.

By the way, does the act of showing AltTab App Switcher window generate any OS-wide events? If it did there could be some other utility that could track those events and filter AltTab and then maybe tell Karabiner?

Apps generate "OS-wide" events in a few ways. You can create an app, like AltTab, which will listen to Accessibility APIs. This way, if an app you listen to creates a new window, you'll get notified. You could listen to AltTab this way, and get events when it shows its main window, the App Switcher window. That can be done through the Cocoa APIs, or through AppleScript, I think.

Well, there is - executing a cli command on 2 events of gaining/losing keyboard focus

As I explained above, there is an open ticket and PR for adding CLI capabiities to AltTab, for such tasks. The work would be hard and long. If you're interested, please feel free to contribute some code and make it happen 👍

Thank you 🙇

[eugenesvk]

AltTab doesn't take focus, then restore it. It doesn't take it in the first place ... can see the blue focus ring around text input

Sorry, this fundamentally doesn't make sense. Keyboard focus is defined re. keyboard input, not visual effects. The cursor in the old app stops inserting input when AltTab is active because keyboard focus is lost. Just like it stops typing when you invoke the official Apple command Move focus to the menu bar - then my cursor keys change the menu (even though in some buggy Chromium apps not only does the blue ring remain, but also the cursor is mistakenly blinking) since the focus has ... moved

You could listen to AltTab this way, and get events when it shows its main window, the App Switcher window. That can be done through the Cocoa APIs, or through AppleScript, I think.

Thanks for the tip, maybe could find some AS example of that

As I explained above, there is an open ticket and PR for adding CLI capabiities to AltTab

And I've already responded to that - that ticket is very different, it's about controlling AltTab from a cli or via XPC, requiring the whole server-client rearchitecture and a lot of work

This would be just making a single subprocess.call after you showing the switcher window. And another one after hiding

[eugenesvk]

By the way, does AltTab code has two easy "entry points" for showing/hiding its window?

Maybe I could simply google and paste the subprocess calls there...

[lwouis]

Yes there are:

• https://github.com/lwouis/alt-tab-macos/blob/4371eb7c39f41645ba017dba6b5283487e8e685b/src/ui/App.swift#L277
• https://github.com/lwouis/alt-tab-macos/blob/4371eb7c39f41645ba017dba6b5283487e8e685b/src/ui/App.swift#L116

Thank you