Second Child Window Placement possible?

[RobinRuf]

Hey guys,

Is there a way (or is it planned) to enable window_placement = second child like in yabai or many tiling window managers for linux?

To explain for those that don't know what I mean: You start a new window. When you open another one, it splits horizontally, of course. If you open a third one, it will split this half vertically, where you had the focus while opening the third window - and so on.

[hwamil]

I think once you have three you have to make the choice to join windows together in a container and each container would occupy their respective estate and would have the effects that you are seeking but there is no automatic configuration for this.

[danfbfern]

@hwamil the fact that you "have" to make the choice is probably the reason that @RobinRuf created the ticket, which is totally understandable.
Coming from Yabai or other tiling managers, this automatic management of the children is something that aerospace should also possibly do.

So currently if you have two windows side by side like this:

h_tiles
├── window 1
└── window 2

When opening a third window, the current behaviour is opening it in the same container, 3 windows side by side like this:

h_tiles
├── window 1
├── window 2
└── window 3

And this is acceptable and might actually be the preferred option if its being used in a ultrawide monitor.
But for the regular monitors like the built-in display, splitting the second and third window vertically would make more sense (OR having to accordion those two) but ideally in that monitor we could have something like this:

h_tiles
├── window 1
└── v_tiles
    ├── window 2
    └── window 3

This is possible by joining the window 2 and window 3 after opening the window 3, but there could be an option to automatically join that new window.

[hwamil]

@danfbfern Yeah, I was just answering his question. I'm a layman so that's all I can do :(

[hisbaan]

I've been thinking about writing a script for this but I'm new to AeroSpace and don't know if any hooks are provided (and also haven't used macOS in quite some time). Assuming some kind of hook was provided and there was some way to get the current node's orientation you could do something like:

on window open {
  if (current orientation == horizontal) { join-with left }
  if (current orientation == vertical) { join-with up }
}

And AeroSpace's enable-normalization-opposite-orientation-for-nested-containers = true would take care of the rest

To add some SEO to this topic, the layout is also sometimes called "spiral" or "dwindle"

[hisbaan]

Just did some more digging and there is a callback system, but it doesn't support very much right now. If we were able to get support for checking node orientation and arbitrary command execution then the whole script could be something like this in your config:

[[on-window-detected]]
if.node.layout = 'horizontal'
run = ['join-with left']

[[on-window-detected]]
if.node.layout = 'vertical'
run = ['join-with up']

(see the related issue)

[gldtn]

@hisbaan

Just did some more digging and there is a callback system, but it doesn't support very much right now. If we were able to get support for checking node orientation and arbitrary command execution then the whole script could be something like this in your config:

[[on-window-detected]]
if.node.layout = 'horizontal'
run = ['join-with left']

[[on-window-detected]]
if.node.layout = 'vertical'
run = ['join-with up']

(see the related issue)

This is exactly what I tried initially, but like you said, unfortunately the callbacks at its current state is very limited. I came up with a shell script that seems to be working as intended; BSP tree like yabai provides. I first tried keeping normalization enabled but as it was a bit confusing and wasn't exactly sure how it works, I decided to disable them and use the traditional i3 splits that aerospace provides(horizontal/vertical/opposite).

The way I have setup as of now is:

aerospace.toml

after-startup-command = [
  'exec-and-forget ~/.config/aerospace/scripts/bsp_tiling.sh',
]
### Normalizations
enable-normalization-flatten-containers = false
enable-normalization-opposite-orientation-for-nested-containers = false

Which means you will not be able to use the join-with commands and have to rely on i3 like split command: https://nikitabobko.github.io/AeroSpace/commands#split

I have no idea if keeping enable-normalization-opposite-orientation-for-nested-containers = true makes a difference on i3 like config as @nikitabobko has it off on the example given. I'm assuming it does nothing on i3 config. From my testing it seems that it should stay false

Again, I'm still testing this and have not shared yet because I'm not sure how well it's working with different scenarios. The way the script works is by querying aerospace for window count and if the current focused space only has 1 window open, and a new window spawns, it splits horizontally. Every spawned window after that, it takes advantage of the split opposite command.

Another thing I'm not happy about it, is the while loop which keeps polling for new window at currently 50ms. Setting too high will mean you can't spam spawn new windows or the script will not detect it. setting too low, it will require a lot of resources. I feel if @nikitabobko adds a callback or a way to query for things like this it would probably eliminate the need to run loops on scripts like this.

Also, this does not take into account when you have float/accordion layout set. I don't have much use for it, but I use it time to time on one of my workspace. I'll try to tackle this later, but again I believe there is no way to query aerospace for current space layout. @nikitabobko sorry for all the tags, I was going to verify and open a suggestion for this, but I hope you get to read this when you have time.

Anyways, here is the script for those that want to try it out and see how it's working and maybe someone with more expertise can chime in and help out:

bsp_tiling.sh
*** make sure to chmod +x bsp_tiling.sh

#!/bin/bash

# Kill any existing instance of the script
pkill -f "$(basename "$0")" 2>/dev/null

# Initialize previous window count
previous_window_count=$(aerospace list-windows --workspace focused --count)

# Arrange windows dynamically
arrange_windows() {
    # Get current window count
    current_window_count=$(aerospace list-windows --workspace focused --count)

    if [ "$current_window_count" -gt "$previous_window_count" ]; then
        # Get the number of windows in the focused workspace
        workspace_window_count=$(aerospace list-windows --workspace focused --count)

        if [ "$workspace_window_count" -eq 1 ]; then
            # If only one window, split horizontally
            if aerospace flatten-workspace-tree && aerospace split horizontall; then
                echo "New window split horizontally"
            else
                echo "Error: Could not split horizontally"
            fi
        else
            # Otherwise, split with opposite orientation
            if aerospace split opposite; then
                echo "New window split with opposite orientation"
            else
                echo "Error: Could not split with opposite orientation"
            fi
        fi
    fi

    # Update previous window count
    previous_window_count=$current_window_count
}

# Main loop to arrange windows dynamically
while true; do
    arrange_windows
    sleep 0.05 # Set polling interval; default 50ms
done

I have echo after each split so I could debug and make sure it was splitting correctly. So if it's acting weird you can run the script manually and see the output on your terminal.

Here is a quick video:

aerospace-bsp_auto_tiling.mp4

[KasselMarc]

I have just tried this out and it seems to work (at least what you illustrated in the video). It doesn't seem to work when moving a window to a workspace that already contains two windows. In this scenario it will again be the 3 windows of equal width placed next to each other (i.e. default behaviour).

[hwamil]

When I move window to another workspace it seems to end up on the right side, so a hacky way to do it is:

[move-node-to-workspace --focus-follows-window foo, join-with-left]

[gldtn]

As soon as I have some time, maybe this weekend.. I'll be taking a second shot at this and see if can come up with a more flexible solution using the recommended Normalizations.

[gldtn]

Just a quick update, I have managed to get a lot further on this. It now takes into account moving windows from one workspace into another. Moving a window to another workspace with up to 6(I believe) workspace should correctly arrange the window into a BSP style. Its not perfect but it works. Hopefully I can convince @nikitabobko to expand callbacks or add event listeners so loops are not necessary here. For example, if on [on-window-detected] we can run the script that would possibly eliminate the loop completely.

If you want to try it out you can download the compiled bsp_tiling file my dotfiles: https://github.com/gldtn/dotfiles/tree/main/aerospace/scripts

Add it to your aerospace.toml config:

after-startup-command = [
  'exec-and-forget ~/.config/aerospace/scripts/bsp_tiling',
]
### Normalizations
enable-normalization-flatten-containers = true
enable-normalization-opposite-orientation-for-nested-containers = true

Let me know how it goes!