How windows are determined to be eligible for management
- Dominant language
- C
- Stars
- 29.6k
- Forks
- 750
- PR merge metrics
- No merged PRs in 30d
Description
The following is an attempt to describe how exactly yabai determines that a window is eligible for management. "Management" entails that the window is allowed to have its properties modfied. If a window is *not eligible* for management, yabai has not touched a single property of said window; it is only tracked for debug purposes (e.g: we *only read* information about the window).
The situation is a bit messy because a lot of the elements that are visible on the screen on macOS is reported as "a window". There are multiple attributes reported through APIs that we can use to determine which type of window it is, but *very often* these attributes are not set correctly by the application/window. This applies to both Apple and third-party software, and makes this seemingly simple job of distinguishing between an application window, dialog window, popup window, autocomplete window, language input-switcher window, etc. quite difficult.
TODO: write stuff
- Windows with subrole kAXUnknown are fully ignored (not managed, not tracked for debug purposes).
- Detect if root-window. if no; window is not eligible for management (tracked for debug purposes -- read only).
- A real window has AXRole = AXWindow and AXSubrole = AXStandardWindow, AXDialog, or AXFloatingWindow.
- If window DOES NOT have a level of 0 ([kCGNormalWindowLevelKey](https://developer.apple.com/documentation/coregraphics/cgwindowlevelkey/kcgnormalwindowlevelkey?language=objc)) it will be treated as a floating window permanently (unless a window rule has been created that sets manage=on)
- If window has AXRole and AXSubrole identifying it as a real window OR a window rule has been created that sets manage=on, this window is eligible for management.
- If window does not have AXRole and AXSubrole identifting as a real window AND no window rule with manage=on, window is not eligible and only tracked for debug purposes.
- Even if a window is eligible for management, only *standard windows* (subset of a real window -- e.g not dialogs) can be *tiled* unless a rule specifies the AXRole and AXSubrole filter with the manage=on property.
- Only windows eligible for management is reported through *window_created* and *window_destroyed* signals.
Contributor guide
No contributing guide indexed for this repository
Research direction
Begin with the AXRole/AXSubrole, root-window, window-level, and manage=on rules listed in the issue. Document the eligibility decision and how it affects tracking, tiling, and window_created/window_destroyed signals; done means the rules are complete and unambiguous.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos
- Domain
- documentation, operating-systems
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100