Native macOS Big Sur tabs are considered windows
Hello everyone! When I open two or more IDEA projects with tabs. IDEAs take up space as white space.
Follow the steps below to reproduce
1.
3.open projects
macOS accessibility API reports tabs as windows. The issue is reproducible in Finder, Terminal.app, TextEdit, etc
Workaround: don't use this macOS feature. AeroSpace offers accordion layout that can be used as a replacement
References:
- https://github.com/koekeishiya/yabai/issues/68
- https://github.com/ianyh/Amethyst/issues/633
It's solved, thank you for your wonderful answer. 🎄🎁
I'd like to keep it open because there might be ways to detect such windows
could yo detect them by checking whether they are all the same size and also in the foreground at the same time or have the same z-index or something like that?
Just adding more context on this issue, since :
In particular, I'm interested in issues that block you from using AeroSpace on daily basis.
I got a workflow where I am dealing with some scripts in terminal where I need to have at least 6/7 tabs open per terminal. So most of the time, I have a setup where I am using 3 verticals terminals windows with Rectangle, with around 10 tabs. Also, this issue seems to happen with others app too, like Fork. So yeah, just to say that, as a user, may be hard to workaround over all the specific edges cases that trigger this behavior.
I also just found out about this the hard way. By switching between the tabs in Finder a few times I even got Aerospace to crash. If you tell me where to find it, I can attach a log.
Hm, I found the location where the log is supposed to be in another issue: /tmp/bobko.aerospace/runtime-error.txt. But that folder unfortunately doesn't exist for me. 🤷
Hm, I found the location where the log is supposed to be in another issue: /tmp/bobko.aerospace/runtime-error.txt
AeroSpace detects some of its crashes but not all of them. If AeroSpace manages to detect the crash then Terminal.app is opened with the crash log and the crash log is located in /tmp/bobko.aerospace/runtime-error.txt
In your case, it's probably a more severe crash. And AeroSpace couldn't detect it. You can find logs of severe crashes in Console.app
You are right, I found it via Console. Had to zip it for Github to allow me to upload it though. 😅
@ubuntudroid thanks for the report! Your stacktrace is the same as in #164
Looks like Amethyst somehow works around this issue since windows with native tabs stay balanced most of the time. In worst case scenario if I spam tabs too much it swaps places with other window. Other than that it works.
So there is a workaround? i tried
defaults write NSGlobalDomain NSWindowTabbingEnabled -bool false
But still new terminal tabs are interferencing with aerospace.
I got a workflow where I am dealing with some scripts in terminal where I need to have at least 6/7 tabs open per terminal. So most of the time, I have a setup where I am using 3 verticals terminals windows with Rectangle, with around 10 tabs. Also, this issue seems to happen with others app too, like Fork. So yeah, just to say that, as a user, may be hard to workaround over all the specific edges cases that trigger this behavior.
I know this is not a generic answer for all those cases, but at least for terminal, you could consider using something like tmux, where the concept of "terminal tabs" would translate to "tmux windows"
in my case I'm getting conflicts for librewolf and some other apps, like Alacritty or Slack, etc
is there anything I can try to do to fix it?
oh, the issue is related to when I'm actually restoring my session, I guess this would be similar issue then for firefox
This problem shows up with Skim too. I understand the difficulty presented by the way the system reports the tabs. But, the accordion solution is maybe a bit tedious. I often have a terminal window on the left of the screen and several tabbed pdfs on the right. If I understand correctly, I would have to join each new pdf to the other pdf windows and make sure that set is in accordion layout. But, then, the orientation of the accordion is not horizontal. Basically, the multiple steps required to arrange things compared with the system's method of automatically tabbing windows of the same application together is taxing. Is there a rule I could set that would automatically group windows of the same application in the same workspace?
I guess this explains why IntelliJ takes over multiple of my workspaces and sometimes fools me into thinking AeroSpace is broken (but really it's just that one workspace is one "tab" within intellij, another workspace is another. I landed here after checking all intelliJ keybindings for option-3/4). Particularly confusing when there's a floating settings menu open in one, but trying to open settings from the other workspace feels like a no-op (cause it's opening in the other WS). Now that I know, will report back here in a week or so if still feels buggy. May just be something we need to document, for now (though the floating window behavior could maybe be made more intuitive)
If there was a way to configure that if a new window of the same application is opened while the current focused window is of that application to instead add the window under a new or current node for that window with accordion layout. This way, opening new tabs with Cmd+T in Finder would create the accordion layout needed to maintain navigation between tabs.
AltTab combines native tabs into a single item. By changing the settings, tabs can be separated into separate items as windows. https://github.com/lwouis/alt-tab-macos
@nikitabobko How about mimicking the logic of AltTab? https://github.com/lwouis/alt-tab-macos/issues/1540
What if there was a way to do it in the config? For example, you can do a on-window-detected or smth, configure what the new tab hotkey is in that application is, and aerospace then detects if that key is pressed and a new "window" was opened, and then just not tile it.
[[on-window-detected]]
if.app-id = 'com.mitchellh.ghostty'
run = "move-node-to-workspace T"
new-tab-hotkey = "cmd-t"
dont-tile-tabs = true
or something in this trend, i think this idea might work although not perfect
Just wanna say it's pretty sad that pretty much everything MacOS native for window management (spaces, fullscreen mode, native tabs, ...) end up making things harder for actual good window management tools.
Alt-tab does it pretty well and I'm looking forward to a workaround here too!
Hi,
AltTab's author here. I was actually hoping someone else would try and find a good solution for this issue. There is no perfect to do it since we lack the public APIs.
Feel free to copy AltTab's implementation. That being said, please understand that it's not perfect. And if you would invest some time to try and solve it with your own approach, I would be very interested in that of course!~
Thank you 🙇
Correct me if I'm wrong but I believe the AltTab implementation uses a private API in CGSCopyWindowsWithOptionsAndTags. One of the stated project values of AeroSpace is to avoid things like private APIs as much as possible so I wouldn't expect @nikitabobko to accept a PR copying the AltTab implementation over - though I'd be happy to be proven wrong
I think for aerospace a great option would be to just have a mark-tab API similar to what @FormalSnake described, to mark a given window as belonging to a tab. That could help to incrementally work towards a solution for this. mark-tab as an API could allow one to set up a global keybinding for cmd-t that runs something like aerospace mark-tab --focused && osascript new_tab.scpt && aerospace mark-tab --focused --join-with-last where the new_tab.scpt uses the New Tab menu bar item of the app to make a new tab. It wouldn't be perfect but the same thing could later be used if keybindings per app get implemented
I found a weird behaviour when trying to manage this issue, which I'm kind of using as a workaround:
Note: I can only get it to work when starting with Finder plus 2 other app windows in a workspace. Finder plus one window never seems to exhibit this corrective behaviour.
- Open new Finder tab and get the ghost window
- Switch Finder to floating #this is the key
- [Mess around with]* changing focus/moving windows and Finder will reinsert itself into the tiling tree correctly and the ghost is gone and focus navigation now works between app windows and across the Finder tabs.
NOTES: Finder still seems to be in floating mode, even though it behaves like a tile (ie. when the extra tab is closed, Finder reverts to floating)
*Mess around with: Sometimes after floating the Finder, just an alt-arrow to switch focus will snap finder back into the tile layout, but sometimes it seems to need alt-shift-arrow (attempt to move the window) instead.
Once there are 3 or more tabs in Finder, the focus nav gets messy, as the tabs seem to be in an inconsistent horz/vert tile orientation, so alt-left/right to move focus across the windows might get stuck at one of the tabs and requires some alt-up/down to move focus across the tabs to then continue left/right on the other side to other windows.
Not sure if this might be helpful info, but thought someone might be able to debug the behaviour and see whats happening under the hood for maybe discovering a way to identify tabs correctly and fix the issue...
This issue also affects Ghostty. Now I know why Webstorm/Rider appear to break in Aerospace as well.
I found a workaround for Ghostty:
Configure it to load as floating (reference):
[[on-window-detected]]
if.app-id = "com.mitchellh.ghostty"
run = [
# FIX: this is a workaround for https://github.com/nikitabobko/AeroSpace/issues/68
# this was also observed in:
# - https://github.com/ghostty-org/ghostty/issues/1840
# - https://github.com/ghostty-org/ghostty/issues/2006
"layout floating",
"move-node-to-workspace T",
]
Then after launching Ghostty, hit Shift+Ctrl+; to enter mode service. Hit f to toggle off floating.
Now you can add tabs (Cmd+t) without having the window reserving dead space next to it.
I found a workaround for Ghostty:
Configure it to load as floating (reference):
[[on-window-detected]] if.app-id = "com.mitchellh.ghostty" run = [ # FIX: this is a workaround for https://github.com/nikitabobko/AeroSpace/issues/68 # this was also observed in: # - https://github.com/ghostty-org/ghostty/issues/1840 # - https://github.com/ghostty-org/ghostty/issues/2006 "layout floating", "move-node-to-workspace T", ]Then after launching Ghostty, hit
Shift+Ctrl+;to entermode service. Hitfto toggle off floating.Now you can add tabs (
Cmd+t) without having the window reserving dead space next to it.
This doesn't always help. I've been experiencing it where each tab has it's own layout set with either tiling or floating and I have to then go through every tab and go through service mode to change its layout.
Any update with this?
I really like AeroSpace but might have to switch due to this issue
Would it be possible to make Aerospace ignore, via config file, new windows created events form some programs to be able to work around this issue?Ideally you could switch the ignore on or off.