Handling native fullscreen, hidden applications, minimized applications

[barlevalon]

I often find myself going into native fullscreen with a certain app (video, game, whatever), and swapping back and forth between it and other open (non-fullscreen) windows.

At the moment, when an app is in native fullscreen, (or hidden, or minimized,) it leaves a hole in the layout.
This behavior feels less than ideal for a tiling window manager, I would expect there to never be a blank space in the layout.

You could argue for not using native fullscreen at all, but then there's no way to fully maximize videos for example (hiding the title bar etc). I could live without minimizing/hiding though.

I do see the value in preserving the window position in the layout. Perhaps windows in native fullscreen can be automatically made floating (and then toggled back when un-fullscreened), or moved to a hidden workspace (like the i3 scratchpad) and then moved back?

[nikitabobko]

My response can be found here: #11 (comment)

Right now, this issue is not a priority for me

[nikitabobko]

Answer to @ullasholla #36

Right now, I don't expect users to use "minimize" and "hide application" because these operations are not presented in i3. I don't use these features, so I didn't take care to support them "properly" (whatever "properly" is supposed to mean in this context). They work as they work in AeroSpace.

I don't understand how such windows should be handled from the UX point of view. When users unhide/unminimize windows, shall I re-attach the windows to where they were in the tree? Or shall I rather attach them to the currently active workspace?

If you describe your use cases, it will help to make the right decision

[ullasholla]

First of all, thanks for your time @nikitabobko.

I don't understand how such windows should be handled from the UX point of view. When users unhide/unminimize windows, shall I re-attach the windows to where they were in the tree? Or shall I rather attach them to the currently active workspace?

If you describe your use cases, it will help to make the right decision

I've previously used Amethyst, and in Amethyst, handling this scenario is akin to closing a window. Unhiding the application is treated as adding a new node. That's what I'm used to. I also use i3, and if someone were to inquire about the 'right' approach, I'd be at a loss :)

Honestly, I'm not overly concerned about where the window gets added. I just find the gaps left behind a bit jarring.

[MatthiasGrandl]

Disclaimer: I haven’t played around with Aerospace yet. Planning on setting it up soon though.

The fullscreen issue is something that annoys me on every window management solution on MacOS.

My ideal solution would be:

1. I have a browser on space 2, I fullscreen a video in this browser and a MacOS fullscreen space pops up
2. I switch to another space
3. If I switch back to space 2, it instead takes me to the fullscreen MacOS space. When I close the fullscreen window I am back on the actual space 2.

This would emulate the behavior from Linux WMs. The only drawback is that you have to resort to the MacOS default workspace switching in this specific scenario.

--

EDIT: Disregard my comment. This already seems to be working the way I expect it to.

[januz]

@nikitabobko I've never used i3, so yabai's behavior made sense for me--if I'm hiding an application, its space is used by the remaining applications, if I unhide it it's added back (I think that either trying to restore its place in the tree or adding it like a newly opened application would be okay).

What are you doing in i3 if you want to show a window, then hide it (i.e., not take it up space in the current view anymore) but want to be able to bring it back at any time in the same status? Are you moving it to the scratchpad workspace and bringing it back.

Would that be what you recommend for users of AeroSpace, i.e., use one workspace as a scratchpad and summon windows? If so, how would one set this up?

[nikitabobko]

@januz

Would that be what you recommend for users of AeroSpace, i.e., use one workspace as a scratchpad and summon windows?

That's exactly what I do if I want to hide the window temporarily. In my workflow, I dedicate one of the workspaces for "hidden" windows. Hiding windows is clear - you just move the window to the dedicated workspace.

If I want to unhide the window:

1. I switch to the dedicated workspace
2. Focus the window
3. Move the window to whatever workspace I need to OR if it's quick I can quickly do the job in the dedicated workspace

If so, how would one set this up?

I don't understand why a special setup is required. In my case, It's just a matter of workflow

[januz]

@nikitabobko Sorry, with "setup" I meant whether you have some command set up (or whether it's possible) to summon a specific window from the scratchpad from the original workspace.

With window hiding in yabai, it's really easy (1 step) to get the window one hid back to the workspace it was on when one hid it. With what you describe, it's easy to hide a window but getting it back to the original workspace takes several steps.

I guess one could set up specific commands for specific applications but it seems harder to just get any window back to the workspace. That's where I feel filling up the space taken up an application if it gets hidden and adding it back to the workspace if it is selected again, would make things easier.

[alper]

I think to keep the existing mental model it'd be ok to consider hidden windows "closed" and then if they're unhidden to treat them the same way as other windows that open.

[geert-plessers]

I also have the habit to Cmd+H or Cmd+M windows to quickly get rid of them. I would consider these windows to be virtually closed when using Aerospace and have the remaining split app to take up the old space of the hidden app.

[Hackmodford]

I’m kind of surprised Aerospace puts windows in the corner instead of hiding them.

[nikitabobko]

0.9.0 fixes the issue

• Hidden apps and minimized windows are treated as closed windows (they don't belong to the workspace).
  • Motivation 1: Discord window close issues #77 (some apps use "hide" to close their windows)
  • Motivation 2. You can use minimize and hide app to hide windows, and then "summon" them back
• Fullscreen windows are treated almost like floating windows (they belong to the workspace, but it's impossible to focus fullscreen windows with focus command). Motivation: Handling native fullscreen, hidden applications, minimized applications #18 (comment)

The project now accepts funding https://github.com/sponsors/nikitabobko

[nikitabobko]

Hidden apps and minimized windows are treated as closed windows (they don't belong to the workspace).

I tend to think that this was a wrong decision for hidden apps and I plan to change it in the next version. Windows of hidden apps should retain their attachment to workspaces when hidden.

It's irritating to accidentially hit cmd-h and loose workspace assignment for several windows #425

I don't plan to change the behavior for minimized windows yet (so you still be able to use minimize and unminize to "summon" windows)

If you think otherwise and like the current behavior for "hide app" please speak up