-
-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better tabs detection #1540
Comments
FYI, we can't use the Accessibility API to simply ask the tab-group for its children. The API simply doesn't return children windows. We can only ask children windows of the whole app, and we will get a single list, with no sorting depending on which tab-group the windows are in. Furthermore, the OS handles tabs in a lazy way. A window becoming a tab will not be resized, repositioned, and redrawned, until it is clicked/seen by the user. So after a user makes a window a tab, if they don't click on it, and we make an Accessibility call to get its size, position, or screenshot, we will get the values of when it used to be a window - so completely wrong. |
I looked into the APIs discussed here: let wins = SLSCopyAssociatedWindows(cgsMainConnectionId, wid) It returns the same ID as the one given as input let query = SLSWindowQueryWindows(cgsMainConnectionId, [wid] as CFArray, 1)
let iterator = SLSWindowQueryResultCopyWindows(query)
while SLSWindowIteratorAdvance(iterator) == .success {
let parent_wid = SLSWindowIteratorGetParentID(iterator)
let wid = SLSWindowIteratorGetWindowID(iterator)
let tags = SLSWindowIteratorGetTags(iterator)
}
var windowList = [] as CFArray
var windowCount = 10 as UInt
CGSCopyWindowGroup(cgsMainConnectionId, wid, "movementGroup" as CFString, &windowList, &windowCount)
I think these APIs are meant to handle child windows, and not tabs. |
I looked into it more today:
So at a given point of time (e.g. on initial launch), without prior knowledge, there is no way to know which windows are tabbed. Can't use their name, position, other attributes; they are not precise enough. That's why today we look for the only event that triggers when the user tabs/un-tabs a window: But I've found a replacement I think. I observed that the following APIs will list windows, or not, in the following cases:
Interestingly The big advantage of this CGS API over the current AX API is that AX APIs can block for a long time, as the OS is asking the app for accessibility data. If the But since the CGS API is pretty fast, we can run it on every AltTab trigger. This way we don't need to observe It's exciting because it should be more reliable than the flaky current approach, and importantly, it should stop breaking apps and the OS. My only concern is: is the CGS call always fast enough, or could it delay the display of AltTab's UI? Also: this still doesn't let AltTab list tabbed windows that existed before it was opened. This can be pursued in the scope of #447. |
You can pass |
@yossizahn Safari and iTerm2 tabs aren't standard tabs. They are custom UI painted inside an NSWindow. So there is no chance AltTab can get information about them. Imagine that it's only when you click on a non-active tab that these apps will draw their content on screen. We can't get the screenshot of these since they are not NSWindow instance and are rendered lazily when shown, on top of the same NSWindow instance. That's why the preference is called "Show standard tabs as separate windows" and not "Show tabs as separate windows". Standard tabs are specific tech from macOS SDK that lets you merge windows together seamlessly. What these 2 apps are doing is custom UI / custom rendering of pixels on screen. |
@lwouis Thanks for the reply, but I still don't understand. Edit: NVM, I just noticed #1656 it seems fixed now |
Yes, sorry @yossizahn, I forgot to update you here when I realized through #1656 that it was an actual regression. Hopefully you can use the latest version and your problem will be gone~ |
No need to apologize, thanks for a great app! |
Today, AltTab uses a full bag of tricks to detect windows which are grouped as tabs. These tricks have limitations that result in features we can't provide, and bugs where AltTab fails to show or not show certain windows.
Current implementation (very simplified and high-level)
kAXFocusedUIElementChangedNotification
on every appLimitations / Bugs
kAXFocusedUIElementChangedNotification
doesn't cover all use-cases for tabs, and doesn't happen always at the right time (i.e. it may trigger too early or too late, and we get the wrong understanding of the OS state)Literature
The text was updated successfully, but these errors were encountered: