-
-
Notifications
You must be signed in to change notification settings - Fork 298
Description
Tiling windows management is uni-directional in AeroSpace. AeroSpace is the owner of the state, and it enforces positions of the windows in the idempotent style. AeroSpace effectively ignores what macOS thinks about windows' position and size. Side-effects flow only in one direction - from AeroSpace to macOS. All good, all reliable
Floating windows are not like that. Their management is bi-directional. AeroSpace has to listen what macOS has to say. For example, it will cause problems for floating windows in the following scenario aerospace eval 'move right --floating-pixels 50; move right --floating-pixels 50'
(#278)
I was inspired to write this issue because I already spent some brain power on #1492 but I don't know the right solution yet. Unfortunately, the priority of this issue is really minor since I don't care about floating windows much, so this issue is probably gonna just rot.
Possible solutions
Turns out that there are already a number of places in AeroSpace (hmm, only 2?), where we have to deal with the problem of bi-directionality
- Focus handling is bi-directional. Right now, AeroSpace implements
lastKnownNativeFocusedWindowId
approach where the focus from macOS is applied only when thelastKnownNativeFocusedWindowId
changes. Downside if we apply it for floating windows: in every refresh session, AeroSpace will have to query all visible floating window's position and size which doesn't sound good for performance, or use AX notifications, in which I have little trust, hmm hmm hmm - Apply changes from macOS only when the left mouse button is down. If we apply it for all floating windows, the downside is that non-AeroSpace tilers won't work with AeroSpace anymore
Problems it causes
layoutRecursive.swift:layoutFloatingWindow
. Calculate everything against current "physical" positionlet currentMonitor = try await getCenter()?.monitorApproximation
. I find it hilarious. It's just unreliable, and non idempotent, but apparently works- The bug fix for MacWindow.prevUnhiddenEmulationPositionRelativeToWorkspaceAssignedRect: take into account monitor proportions #1492 makes
MacWindow.hideInCorner
behave in the same way.
- The bug fix for MacWindow.prevUnhiddenEmulationPositionRelativeToWorkspaceAssignedRect: take into account monitor proportions #1492 makes
- The mentioned
aerospace eval
problem above