Feature Request: Option to move displays when focusing a space / static ordering

[jneen]

Hi all,

Thank you so much for yabai, it's the only reason I'm able to use a Mac at all given my RSI.

I have one more other issue I deal with, which is short term memory loss. I had worked around this in my Linux days by using XMonad, where there are only 9 spaces and you can put them on whatever space you like without having to "move" them - the displays sort of exist in a static order and telling a display to show a particular space doesn't change their order. For example, if I have 3 displays, and * marks my focus:

[ 1 ] [ 4* ] [ 7 ]
- alt-8 // switch to space 8
[ 1 ] [ 8* ] [ 7 ]
- alt-r // switch to right monitor
[ 1 ] [ 8 ] [ 7* ]
- alt-4 // switch to space 4: automatically moves it to right display
[ 1 ] [ 8 ] [ 4* ]
- alt-8 // switch to space 8: swaps with middle display
[ 1 ] [ 4 ] [ 8* ]

This way, all I need to remember is where I am and where I want to go.

I know Mission Control doesn't... work this way, and when I use multiple monitors I tend to just completely lose track of all my spaces very quickly, since showing them on different displays shuffles around the Mission Control index. I have used the labels @1 through @9 to keep a static order, which works nicely for preventing re-shuffling, but I have run into a few issues with the switching behaviour, namely:

• Spaces get randomly destroyed when you unplug a monitor (Keep windows attached to spaces as displays are disconnected and reconnected? #238)
• Swapping two spaces between the displays (the desired behaviour if the target space is visible on another display) seems literally impossible if both spaces are the last on their display
• Even if I were to create a temporary space, that's a) slow, and b) there seems to be no way to get the ID or mission-control index of the newly-created space, even from within C code
• Inserting a scripting layer to move the newly focused space to the current display works, but is agonizingly slow (requires too much yabai -m query and JSON parsing - half a second to a second of lag every time I switch spaces even if the spaces don't have to be moved to another display, or if there is only one display)
• I've attempted to modify the C source to add an option for space-switching without display-switching, but it seems to get caught in a loop somewhere, flicking between two displays and ultimately crashing the scripting addition >_>. And even theoretically the approach still breaks down in the "swap" case when both spaces are the last on their respective displays.

I'm happy to hack on this more, but I wanted to see if anyone else was thinking along these lines, and/or had any ideas before I get too into the weeds.

Thank you <3
jneen

[jneen]

I have a local branch that has implemented this, which I'm using privately for now to try and smoke out any edge cases. It implements a new yabai -m space --switch <SPACE_SEL> command which has xmonad/i3wm-like semantics. It will still break in the "swap" case if both spaces are the last on their display, but I think a change to the scripting addition might be required for that (or creating temporary dummy spaces on both displays, but that Feels Wrong). I also will have to re-start yabai every time I unplug a monitor due to #238, since my labeled space will disappear.

[koekeishiya]

I did spend quite some time looking into this issue in the past. I'm not going to go into too much detail right now, but as for:

Swapping two spaces between the displays (the desired behaviour if the target space is visible on another display) seems literally impossible if both spaces are the last on their display

I did actually implement this in the space --swap command originally, but did not handle that specific edge case and so I ended up reverting that. In hindsight, the edge-case can be solved by simply grabbing all windows that belong to space A and space B, and simply swap them, instead of swapping the spaces themselves. If the spaces are managed by yabai, it would simply need to swap the internal settings/tree for the spaces as well, and that should work just fine. The OS API that yabai uses to move windows around will correctly normalize the window frame to the resolution of the target display.

[jneen]

Oh that's a really interesting idea! And swapping the internal tree would guarantee the layout and labels and such would be preserved, right?

[koekeishiya]

Yeah. There are a couple of data structures that need to be updated during such a swap, so it might not be the most efficient solution in the world, but it would be a solution.

[jneen]

I had a go at implementing this if you'd like to take a look. It's very likely I'm still missing some state somewhere.

[aiguofer]

man @jneen you're just tackling all the issues I've had with yabai :) great work! looking forward to your contributions. Hopefully you'll make my https://github.com/aiguofer/dotfiles/blob/master/user/.local/bin/yabaictl script obsolete.

[koekeishiya]

Implemented on master:

--switch <SPACE_SEL>

The selected space will always be the currently focused space.
The given space substitutes the selected space, gaining focus.
If the selected space and the given space belong to different displays, this behaves like --swap.
If the selected space and the given space belong to the same display, this behaves like --focus.
System Integrity Protection must be partially disabled.

There is no window --switch .. command, however it would just need to chain the following:

yabai -m window --space 5 && yabai -m space --switch 5

In addition yabai -m space --swap .. now works across displays, with the caveat that it uses this new implementation of moving windows and their state (along with space labels), instead of swapping the macOS spaces.

[koekeishiya]

Fixed in v7.0.0.