Stacking support

[pat-s]

Wondering if you have thought about supporting stacking of windows (similar to i3 and sway).

I usually use this mode a lot in certain spaces in sway and it can be pretty handy.

Thanks for the great project!

[dominiklohmann]

A flexible implementation of this has a lot to offer. Obviously this can already be done using a combination of signals, rules and queries—similar to my monocle mode implementation from #83—but I personally think that yabai has a lot to gain from this if implemented properly.

I'm imagining a syntax like this:

# stack source window on target window
yabai -m window [<source window selector>] --stack <target window selector>

# the next window gets inserted stacked on top of the source window
# the window command --insert currently supports <DIR_SEL>
yabai -m window [<source window selector>] --insert stack

Which would make the source window occupy the same frame and node as the target window. A window could be taken out of a stack through any means that reinserts it, e.g. a warp command.

What still needs to be discussed is how window selectors interact with stacked windows: Should directional selectors (west, south, north, east) ignore stacked windows? Should next and prev cycle through stacked windows in order? Is the focused window always moved to the top of its stack whenever its focused?

How should stacked windows display? Should there be an overlap, e.g. the lowest window of the stack using the full height of the stack, the 2nd lowest has its frame start a set amount of pixels lower, the 3rd lowest has its frame start twice the set amount of pixels lower and so on? That way, mouse support would not be compromised. I would suggest using 22pt here, which is the height of the menu bar.

Some form of stacking could also be the foundation for fixing #68 (would require the internals to be changed in a similar way anyways) and would allow a more robust implementation of a monocle mode, and many more custom ways to tile windows like suggested in #98.

Thoughts @koekeishiya?

[koekeishiya]

I do see the use case for this type of window management, but I am currently not interested in attempting to implement this. I would not be against a well thought out PR that integrates this nicely if anyone wants to give it a shot on their own.

[Krever]

Just to share some explanation on why I think this is a very VERY useful feature (for me at least):
I typically work with several (2-8) instances of IDE (Intellij). What I got used to (on i3wm) is having one instance open as fullscreen and the other ones visible only as window titles. Then whenever I need to switch I use arrows to navigate through the windows titles. What's important is that I completely don't care about any visuals or interactivity of these other windows.

I'm trying to use amethyst right now but the closest I was able to get is a huge pain in comparison to i3. Mostly because it's very hard to identify which window I want to switch to. They all look almost the same and titles are not well exposed.

[koekeishiya]

To clarify, my main issue with this is not inherently the functionality by itself. It is the fact that macOS does not actually expose the functionality necessary for me to implement the various solutions that would make this a good experience, and so I'm reluctant to spend too much of my time dealing with their garbage.

I have this in the back of my mind and iterate on possible solutions that could work, but this is not as simple to solve as it would be with e.g the X windowing system.

[koekeishiya]

Implemented basic logic and structure necessary for stacking windows.

Directional selectors will ignore the additional stacked windows belonging to a node (meaning that they will target the currently focused window in the stack).

Stacked windows are not cascaded; their region overlap as is. If a stacked window activates parent zoom or fullscreen zoom, that operation will simultaneously apply to all windows in the same stack.

To make a window share node/region with some managed window, use the following command:

# stack target_window_sel onto source_window_sel
yabai -m window [<source_window_sel>] --stack <target_window_sel>

# next window is inserted onto source_window_sel
yabai -m window [<source_window_sel>] --insert stack

# focus the prev window in a stack
yabai -m window --focus stack.prev

# focus the next window in a stack
yabai -m window --focus stack.next

# focus the first window in a stack
yabai -m window --focus stack.first

# focus the last window in a stack
yabai -m window --focus stack.last

# focus the most recently focused window in a stack
yabai -m window --focus stack.recent

<target_window_sel> will take on the node/region of <source_window_sel>. The reasoning behind the arguments working in this order is that I find it more intuitive due to the way that you can omit the <source_window_sel> to implicitly place an arbitrary window onto the currently focused window.

To un-stack a window, simply perform a warp operation using window --warp or using mouse integration, with the stacked window as the source operand. When a stacked window is the source operand of a mouse action it is not eligible for a swap operation, and it will always perform a warp following the regular rules, in which the end result is that the window is split into its own separate node. If a regular managed window (non-stack) is the source operand of a warp/mouse operation it will follow all the regular rules.

With the exception of mouse integration, swap operations should work as it always has.

If a stacked window is moved to a different space/display, enters fullscreen, or any operation that would make this window become unmanaged, that operation will only affect that window and it will be removed from the stack.

---

Remaining things that need to be implemented/solved:

1. How to focus stacked windows? New command/selectors or make prev/next cycle through stacked windows in order? Implemented.
2. • Is the focused window always moved to the top of its stack whenever its focused?
   • Properly track the focused window in a node when it has multiple windows (if it is not moved to the top of its stack). Implemented.
3. Support stacking through window --insert. Implemented.