Preserve position for native fullscreen window after exiting

[bin101]

I built a snapshot from commit 0589ac7 and noticed that when entering native fullscreen, the window is detached and when exiting native fullscreen, the window is reattached after the last focused window and does not return to the last known position.

I found this where @nikitabobko said this is the intended behaviour, but also this that at least the behaviour for hidden windows should be changed to preserve the position in the tree.

This is more of a feature request to rethink the native fullscreen behavior. At least for me, it disturbed my workflow, as I have an ultra-wide monitor with multiple browser instances in a horizontal accordion container and keep my IDE next to it on the same workspace, and switching back and forth between native fullscreen in a e.g. Youtube video completely destroys my layout.

aerospace CLI client version: 0.0.0-SNAPSHOT 0589ac7d3071042e0c17e80dd517a0bcdbf798e9
AeroSpace.app server version: 0.0.0-SNAPSHOT 0589ac7d3071042e0c17e80dd517a0bcdbf798e9

[nikitabobko]

but also #18 (comment) that at least the behaviour for hidden windows should be changed to preserve the position in the tree.

No, you're reading it wrong. Windows of hidden apps will preserve their workspace assignment. They will work in the same way as macos native fullscreen windows do right now.

---

As of your overall request - a particular proposal of the algorithm should be made on how to attach windows back to the tree where they were. I already briefly described the essence of the problem here #188 (comment)

[bin101]

I though yabai had a solution but it didn't and I don't feel smart enough to have a complete solution for this problem.

Could it be one first step to persist the state of the tree before entering the native fullscreen and only use the current implementation if the tree cannot be restored? I mean this should only be the case if the branch containing the now native fullscreen window was modified somewhere on the way back to the root or am I wrong?

[bekaman7]

@nikitabobko Couldn't aerospace create a placeholder window for the fullscreened app with the same exact dimensions which would hold its place in the tree and could be replaced by the original window when the fullscreen is left? I know we would be quite close to the phantom holes you describe but we could write like "App in Fullscreen" on the placeholder window and move to the fullscreen "space" when it is clicked.
Since I don't know the codebase of aerospace I don't know how feasible this is or if it just sounds stupid. And even if it's doable I see that it's a bit wonky but implementing this would greatly reduce the annoyance with fullscreens.

[leokeba]

@nikitabobko Couldn't aerospace create a placeholder window for the fullscreened app with the same exact dimensions which would hold its place in the tree and could be replaced by the original window when the fullscreen is left? I know we would be quite close to the phantom holes you describe but we could write like "App in Fullscreen" on the placeholder window and move to the fullscreen "space" when it is clicked. Since I don't know the codebase of aerospace I don't know how feasible this is or if it just sounds stupid. And even if it's doable I see that it's a bit wonky but implementing this would greatly reduce the annoyance with fullscreens.

Why would you want a placeholder window with the original dimensions ? It seems to me that ignoring the window (ie: 0px dimension and no interaction) with a kind of "fullscreen" flag would make more sense. Also, I think drawing graphics (for the placeholder window) is currently out of the scope of the project, as all it does right now is interact with the preexisting window system, but it does not create any windows or graphics.

As of your overall request - a particular proposal of the algorithm should be made on how to attach windows back to the tree where they were. I already briefly described the essence of the problem here #188 (comment)

How about just not detaching it ? The "phantom window" problem could be easily resolved with the use of a flag to ignore its size. As for the behaviour regarding tree modifications, I think disabling all user-triggered actions (move, focus, etc.) but keeping automatic transformations (flatten, etc.) active could do the trick.

If the tree structure is unmodified, the window comes back exactly where it was, and if the structure has changed, then it lands where it would have gone with the modifications that were applied.

Maybe there would be a few edge-cases to cover, but this approach seems sound to me. Am I missing something ?