Feature idea: add a primary-secondary layout command

[alexrochas]

I’d like to propose a built-in primary-secondary layout command.

Heavily inspired by Xmonad

Use case

A common workflow is to keep one “main” window large and visible at all times, while the remaining windows live in a secondary vertical stack.

Examples:

• video call or chat app as the primary window, with terminals/editors/browser windows in the secondary column
• editor as the primary window, with docs / terminal / preview in the secondary column
• browser as the primary window, with supporting apps stacked to the side

Today this can be approximated manually by reshaping the tree, but it is not very convenient to re-establish quickly or to promote another window into the main position.

Proposal

Add a command:

aerospace primary-secondary

Behavior:

• the focused tiling window becomes the primary window
• the workspace is reshaped into a horizontal split
• the primary pane gets about 70% of the width
• the secondary pane gets about 30% of the width
• all other tiling windows are placed in a vertical stack in the secondary pane

If the workspace is already in this layout, running the command on another focused tiling window should promote that window into the primary pane.

Mental model

This is not meant to be a separate global layout engine.

It is a practical tree transformation plus layout preservation for a very common “one big window + side stack” workflow.

The user mental model is:

• “make this window the primary one”
• “keep the rest in a side stack”

Why a dedicated command

The value is not only the initial rearrangement, but also:

• being able to bind it to a hotkey
• being able to re-run it to promote another window
• preserving the intended 70/30 shape across relayouts
• routing newly opened tiling windows into the secondary stack while the workspace stays in this mode

Without that, users have to rebuild the shape manually.

Proposed CLI synopsis

aerospace primary-secondary [-h|--help] [--window-id <window-id>]

Alternatives considered

• Manual tree manipulation with existing commands
  • possible, but not ergonomic for repeated use
• A more general dynamic/master layout system
  • more powerful, but significantly broader in scope
• Scripted external solution
  • workable, but less discoverable and less consistent than a built-in command

Experience from testing

I also have a working implementation on my fork and have been using it daily for about two weeks.

So far, the interaction of:

• focus a window
• run primary-secondary
• rerun it on another focused window to promote it

has felt simple and practical in daily use.

I also recorded a short demo from real usage that shows:

• applying primary-secondary
• promoting a different focused window by rerunning the command
• keeping the secondary stack on the side

primary-secondary-demo.mov

Implementation direction

I already have a working implementation in a branch.

The approach is additive:

• introduce a primary-secondary command
• reshape the current tiling workspace into a 70/30 split
• treat the focused window as the primary window
• preserve the ratio during relayout
• place newly opened tiling windows into the secondary column
• allow promotion by rerunning the command on a different focused window

If the direction looks reasonable, I can open a PR with the existing implementation for review.

Questions

• Does this fit AeroSpace’s design goals?
• Is primary-secondary the right naming?
• Is a dedicated command acceptable, or would a more generic mechanism be preferred?
• Is preserving the 70/30 ratio and insertion behavior the right default?