Skip to content

Allow persistent fullscreen mode#1908

Open
waj wants to merge 1 commit intonikitabobko:mainfrom
waj:persistent-fullscreen
Open

Allow persistent fullscreen mode#1908
waj wants to merge 1 commit intonikitabobko:mainfrom
waj:persistent-fullscreen

Conversation

@waj
Copy link
Copy Markdown

@waj waj commented Jan 17, 2026

Add support for windows that stay in fullscreen mode even when another window in the same workspace is focused. This can be done by passing the --persistent flag to the fullscreen command.

PR checklist

  • Explain your changes in the relevant commit messages rather than in the PR description. The PR description must not contain more information than the commit messages (except for images and other media).
  • Each commit must explain what/why/how and motivation in its description. https://cbea.ms/git-commit/
  • Don't forget to link the appropriate issues/discussions in commit messages (if applicable).
  • Each commit must be an atomic change (a PR may contain several commits). Don't introduce new functional changes together with refactorings in the same commit.
  • ./run-tests.sh exits with non-zero exit code.
  • Avoid merge commits, always rebase and force push.

Failure to follow the checklist with no apparent reasons will result in silent PR rejection.

Add support for windows that stay in fullscreen mode even when another window in the same workspace is focused.
This can be done by passing the `--persistent` flag to the `fullscreen` command.
@waj waj force-pushed the persistent-fullscreen branch from 27ee6c3 to 53afd37 Compare January 17, 2026 21:24
@nikitabobko
Copy link
Copy Markdown
Owner

nikitabobko commented Jan 19, 2026

In your current implementation, you can have multiple persistent fullscreen windows. Is it intentional? The alternative implementation could be that focusing non-fullscreen windows doesn't unfullscreen the current fullscreen window; but making another window fullscreen, does.

Doesn't layout accordion work for your use cases?

@waj
Copy link
Copy Markdown
Author

waj commented Jan 19, 2026

Yes, having multiple persistent fullscreen windows is intentional.
Let me explain my use case. I typically use an external big monitor where I put my primary workspace with a layout like this:

+-----+-----+
|  T  |     |
+-----+  E  +
|  B  |     |
+-----+-----+

Where T contains my terminals, B browser windows and E the editors (browser and editors are already accordions). However, when I unplug and take my laptop with me, the built in screen is sometimes too small for this, so I might make the editors full screen while I don't need to see everything side by side at the same time. But still I like being able to navigate between the apps in the same way, or temporarily have the terminal on top of the editor without making it full screen.
When I go back to my external monitor everything is still using the same layout.

I recently moved to AeroSpace from yabai and I missed that possibility. Although in yabai the "persistent" fullscreen is not optional.

I'm thinking maybe an alternative could be adding a flag to the focus command to not undo fullscreen of the previously focused window?

@nikitabobko
Copy link
Copy Markdown
Owner

Thanks for providing more context, my intuition says that having multiple persistently fullscreen windows on one workspace at the same time is flawed/unintuitive. Axiom: there can't be more than one fullscreen window on a workspace.

Being more specific, I think it's PITA to go over windows one-by-one and fullscreen/unfullscreen them. What I feel might be better fit for your workflow is some kind of aerospace monocle command. "monocle" is the boolean flag of a workspace. Monocle mode makes whatever window is focused - fullscreen. Changing focus leads to the newly focused window becoming fullscreen.

The two are mutually exclusive: fullscreen, monocle. Making any window fullscreen cancels the monocle state and vice-versa. Open question: aerospace workspace 1; aerospace fullscreen; aerospace monocle --workspace 2; aerospace move-node-to-workspace 2 (what state workspace 2 is in?)

I almost don't mind introducing fullscreen --persistent but in the way I describe it above. Focusing any other window wouldn't cancel the fullscreen, but making any other window fullscreen/monocle would. I say almost because I am afraid that focused windows that go on top of the fullscreen window might look like broken layout for some users.

Just thinking out loud: fullscreen --follow-focus could be an alternative syntax for aerospace monocle. (But I like --follow-focus idea less)

@waj
Copy link
Copy Markdown
Author

waj commented Jan 21, 2026

I personally don't feel like the layout is broken when a non-fullscreen window gets focused on top of a fullscreen one. For me it feels natural but maybe because I'm used to it. I see it like when terminals are opened in quake mode. But this is personal, it's your project and I respect that. I'm thinking that maybe adding a --no-unfullscreen flag to the focus command might feel less "broken" as it's an explicit action and not something that's constantly kept in the state.

I can see a lot of potential in that monocle mode. Maybe it could support not only fullscreen, but for example it might be useful to enter into a kind of "zen" mode where the focused app gets in the center of the screen probably not using the entire width. It would be glorious if other apps could optionally hide or shade too. I've been looking how to do this, like entering into a temporary floating mode but without loosing their place in the tree.

Davincible added a commit to Davincible/AeroSpace that referenced this pull request Feb 11, 2026
# Conflicts:
#	Sources/AppBundle/layout/layoutRecursive.swift
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants