-
-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AltTab always shows tabs as separate window, when the window is hidden/minimized, on Monterey #2017
Comments
I've noticed this too, but only on Monterey. |
Yes, I think Monterey broke our tab detection. I was able to reproduce with minimized and hidden windows. They show separately even with the preference unchecked. I also noticed that if you check the preference, then bring a window with 2 tabs on another Space, then go back to the first Space, then AltTab to another tab of that window, it will teleport it on the current Space. It seems like a new macOS bug... |
This seems like it could do the trick on the latest OS: +++ src/logic/Windows.swift
@@ -162,8 +162,8 @@
static func detectTabbedWindows() {
- let cgsWindowIds = Spaces.windowsInSpaces(Spaces.idsAndIndexes.map { $0.0 }, [])
+ let cgsWindowIds = Spaces.windowsInSpaces(Spaces.idsAndIndexes.map { $0.0 }, [.minimizedAndTabbed /* or .minimized2 */])
list.forEach {
if let cgWindowId = $0.cgWindowId {
- $0.isTabbed = !$0.isMinimized && !$0.isHidden && !cgsWindowIds.contains(cgWindowId)
+ $0.isTabbed = !cgsWindowIds.contains(cgWindowId)
}
}
}
+++ src/logic/Spaces.swift
@@ -70,5 +70,5 @@
static func windowsInSpaces(_ spaceIds: [CGSSpaceID], _ options: CGSCopyWindowsOptions) -> [CGWindowID] {
var set_tags = ([] as CGSCopyWindowsTags).rawValue
var clear_tags = ([] as CGSCopyWindowsTags).rawValue
- return CGSCopyWindowsWithOptionsAndTags(cgsMainConnectionId, 0, spaceIds as CFArray, 2, &set_tags, &clear_tags) as! [CGWindowID]
+ return CGSCopyWindowsWithOptionsAndTags(cgsMainConnectionId, 0, spaceIds as CFArray, options.rawValue, &set_tags, &clear_tags) as! [CGWindowID]
} or: +++ src/logic/Windows.swift
@@ -162,8 +162,7 @@
static func detectTabbedWindows() {
- let cgsWindowIds = Spaces.windowsInSpaces(Spaces.idsAndIndexes.map { $0.0 }, [])
list.forEach {
if let cgWindowId = $0.cgWindowId {
- $0.isTabbed = !$0.isMinimized && !$0.isHidden && !cgsWindowIds.contains(cgWindowId)
+ $0.isTabbed = cgWindowId.spaces().count == 0
}
}
}
Is it different from the comment below? +++ src/logic/Window.swift
@@ -200,4 +200,4 @@
func updatesWindowSpace() {
// macOS bug: if you tab a window, then move the tab group to another space, other tabs from the tab group will stay on the current space
// you can use the Dock to focus one of the other tabs and it will teleport that tab in the current space, proving that it's a macOS bug
// note: for some reason, it behaves differently if you minimize the tab group after moving it to another space |
Thank you for sharing this. It doesn't work unfortunately. It shows tabs of regular windows as separate windows, always.
You're totally right. It's the same bug I re-"discovered" today I guess. You're very good with the codebase! |
Could you guys please test out this build? It seems to fix tabs issues on my machine |
Hi @lwouis - Thanks for working on this issue! I really appreciate it. Unfortunately, the build didn't solve the problem on my end. But perhaps others will have more luck? Using the build, I'm still seeing minimized tabs, as windows (when testing with Finder using Monterey 12.6.1). Except now I'm also seeing its tabs, as windows, when they're not minimized, too. PS - When I reverted back to 6.48, however, the problem went back to just impacting minimized windows/tabs. |
Still on Monterey 12.5.1 here and it's working as intended for me. |
@jasondm007 I can't reproduce the issue. Could you please share a video with that build and showcase the exact steps you take? |
@lwouis I'm not sure if this is what you're looking for, but after reinstalling that build, and restarting my computer, I created a video for you detailing everything. The video starts by showing the relevant Alt-Tab preferences, and then it illustrates the behavior using a Finder window with three open tabs. As you'll see in the video, each tab is treated like a window whether or not it's minimized. To be clear, however, when I revert back to 6.48, the problem only occurs when the window is minimized (i.e., tabs are not treated like windows, unless they're minimized). Hope this helps clarify things. Thanks again! Kapture.2022-10-31.at.16.02.00.mp4 |
Thank you @jasondm007 for the video. I'm missing the steps prior: how did you create the Finder window with 3 tabs, and when did you launch AltTab (before or after setting the 3-tabs Finder window?). Furthermore, what happens from the point at the end of the video, if you restart AltTab? Also, do you use multiple monitors? And do you have multiple Spaces? |
Actually after testing a bit further, I've realised that after restarting AltTab while a multi-tabbed Finder window was already minimised, I'm now experiencing the same behaviour as in @jasondm007's video. I restarted AltTab again with the window de-minimized, which at first appeared to fix the behaviour. But then every time I focus another tab within the Finder window (via mouse or Finder's own keyboard shortcuts), it shows again as a separate window within the list. I've tried various different combos of relaunching AltTab / Finder / the whole computer since, but always the same result. Also, I have |
Hi @lwouis
From Finder, press ⌘N, then ⌘T twice to open two more tabs in the window. Navigate each tab to the appropriate location.
Mine starts on login. So, to avoid any problems, after installing the dev I restarted my computer (and then performed the steps above). In other words, AltTab was started before setting up the Finder window above.
I just reinstalled the old version of AltTab each time (since version 6.48 only has the problem with minimized windows/tabs)
Yes, one external display with my laptop. Both in use at the same time (and both with separate Spaces).
Yes, I always use several Spaces at the same time (only 1 or 2 on the laptop screen, and several on the large external monitor). FWIW - I've never noticed any differences on different Spaces. Nor has it mattered whether the window was minimized to the dock on either monitor. They all exhibit the same behavior. |
@jasondm007 @frypf I can't reproduce your scenarios on my machine (M2, Ventura). When I launch AltTab before or after I make a 3-tabs Finder window, AltTab always shows 1 window. If I move to other tabs, it shows that 1 tab correctly. What I can reproduce is when the window is hidden or minimized, then I see all tabs as separate windows. Which exact version of macOS are you running? I'm not sure what I can do here. I'll try to set up a VM with Monterey to test it out there. Tab detection has been a nightmare for years now. I know other window management projects as well. |
12.5.1 / M1 here. I didn't have any issue on the test build until I quit & relaunched AltTab while my Finder window was minimised, but nothing I've tried since has managed to revert the behaviour back to normal. If I reinstall 6.48, it goes back to
|
Yes - this is exactly how 6.48 performs on my computer. Tabs are only errantly shown as windows when minimized, but are otherwise displayed correctly when they are not minimized. When using your test build from above, however, all tabs were always treated as windows.
12.6.1 / Intel |
I moved from an Intel to an M2 macbook. I used to have nice VMs to test retro-compat of AltTab all the way down to macOS 10.12. Now on Apple Silicon, I can't virtualize anything. In theory I could have a Monterey VM at best. In practice, I tried Parallels, Virtual Buddy, and UTM, and I only get a black screen when trying to boot Monterey. It's a big issue going forwards, how I should work on AltTab, and QA changes, if I can't test on previous OS myself. Sharing this here so you know the situation. |
# [6.50.0](v6.49.0...v6.50.0) (2022-11-14) ### Bug Fixes * don't show firefox tooltips as windows (closes [#2110](#2110)) ([bf905b1](bf905b1)) * tabs show as separate windows sometimes on monterey (closes [#2017](#2017)) ([0965a78](0965a78)) ### Features * avoid accidental press of the "reset preferences" button ([#2093](#2093)) ([f6fcac5](f6fcac5)) * avoid confusion with native app-switcher (closes [#2080](#2080)) ([f906c0e](f906c0e)) * improve localizations ([2123af3](2123af3)) * show alttab on display with active menubar when needed ([#2107](#2107)) ([917e661](917e661))
Hi @lwouis, I hadn't realised you'd be rolling this change out with 6.50 given your last comment about being unable to QA the change or reproduce the issue. I've just updated (to 6.51) but had to roll back to 6.49 as I'm experiencing
again - on both my Monterey and Mojave machines. Any chance of reverting to the old tabs logic for pre-Ventura installations please? At least then the tabs are only shown separately when the window is minimised, which is infinitely more usable than the current behaviour. I'm guessing this could be also be related to #2136. |
Actually I just did some quick version testing, as I distinctly remember the issue as reported in the title was never originally a problem on Mojave, only Monterey. Monterey seems to have always had the problem with showing minimised tabs as windows regardless of AltTab's version. However on Mojave, the behaviour changed with 6.39.1 - prior to this there was no issue with tabs detection for minimised windows, then from 6.39.1 > 6.49 it's showed minimised tabs as windows. 6.50 & 6.51 are showing tabs as windows regardless of minimised/hidden status on both Mojave and Monterey. |
Hi @frypf, I don't know how to handle this to be honest. I've writen about the limitations I have above, in regards to being able to dev/test these scenarios. I could make some kind of blind change that does different behavior for different macOS versions, but that would be:
I'm not sure what I can do here, since I don't have access to older macOS version now. |
I appreciate your frustrations, I know Apple have never made migrating software between OS versions particularly easy - even more so given the move to their own chips and when you're using private / undocumented APIs. I hadn't actually noticed the change I mentioned for Mojave at all until today, which shows how often I minimise a tabbed window. That being said, from my own point of view I can cope pretty easily with minimised/hidden tabs showing as windows, whereas this new behaviour just completely overpopulates the AltTab switcher and makes using it overall a pretty frustrating experience. I know you're reticent to start adding version flags, but given that the code changes for 0965a78 seem fairly minimal, I'd be really appreciative if it was possible to do so in this instance at least. As far as Mojave is concerned, I'm happy enough living with the behaviour being the same as Monterey as it has been post-6.39.1, rather than adding yet another flag. The fact that there are so few issues reported previously regarding this problem is perhaps testament to how few people are experiencing / noticing it, albeit the fact that #2136 has been added so recently maybe shows that the new behaviour is likely to be more obvious. I can fully understand that this may just start a slow drip of further complexity down the line. My only other option is to stay with 6.49 for now and hope that there's no further must-have features added in the future, but obviously this further reduces your own test-base for new features and fixes on older versions given the issues with doing so on M2/Ventura you mentioned above. I'm only one voice among many who seem keen enough to do such testing and reporting on issues more generally though, and I notice for instance that yabai has recently made the move to stop supporting older OS versions. I really appreciate that you've kept struggling against the tide to provide support for older OS versions, and none of these decisions are easy! |
If I can, I will never stop caring about older macOS versions. The deciding factor here may be that I'm no longer able to experience those versions. I didn't realize this when moving to an M2, and now I find myself a bit trapped as there is essentially no support for any older OS on the machine. I won't buy another Intel macbook just to test AltTab. It feels like I'm at a deadend :/ |
I'm curious if this is from the point of view of the practicality of running a separate machine, or cost (if it's not too impertinent to ask!? - apologies if so). I know you've always had an altruistic vision for AltTab, but there are many issues you've closed asking about setting up a means of donating for all the time you spend finessing it. Would you maybe reconsider this if working specifically towards a modest goal of purchasing a secondhand Intel machine for testing purposes? Just an idea - I'm also aware you're looking to pass the baton to someone else for continued development going forward. I'd guess that for me at least, AltTab is objectively the app I use most often day-to-day. It just works so well in the background that I never even have to think about it most of the time. I wish I was better with Swift / programming in general so that I could actually help drill down into the meat of some of the issues, but my coding experience is very much limited to cludging together little ad-hoc CLI tools to solve issues that no-one else seems to have. Even then, as I've now switched to an M1 Macbook for my main machine, I'd still experience the same issues as you do with regard to easily testing for Intel and older OS versions. I only keep my Mojave machine going to run a few bits of old 32-bit software that will never be updated - and even on a consumer-level that's something I'm finding increasingly difficult going forward. So much for the supposedly seamless transition over to Apple Silicon 🤷♂️. |
It's the fact that I don't want to invest myself that much (buying a second computer just to work on this project) + the cost + the environmental symbolism of having a second computer (reminds me of households with 2 cars). The feeling I get from #1324 is also demotivating. It's a mix of things. I also think about the future, and get sad at what the IPCC is telling us that future will be like. I don't think we'll be discussing AltTab on Github in 20 years. I think we will have more necessary things to worry about. This project is pretty symbolic to me of the end of my innocence. Barely a few years ago, I used to think humanity was going to go more complex, with more technology, that I could make a wonderful career in tech having fun with these abstract puzzles. Now I look at all the science, and I've buried that dream. I'm currently working on a more realistic dream involving living in a small town, of some craftmanship. I realize this answer goes a bit further than was probably expected. Sorry about that. Regarding this specific issue, maybe I could use some Cloud rental for a few hours to try out a build with version-specific branches. Maybe I could just build it based on what you wrote above, and you could test it? Maybe it's enough, and better than status-quo on Monterey/Mojave if we add the special cases. |
No need to apologise - it's interesting to hear the specific motivations behind the project, even if said motivation has understandably taken a dent over the past few years. I only wish I could disagree with you. Either way, your efforts to support old OS versions are admirable and speak to my own frustrations with obsolescence and the rarely considered knowledge / monetary / environmental tradeoffs of relentless progress.
I'm always happy to test out any builds although obviously as you've found, everyone seems to use AltTab differently, and even with regular day-to-day use a problem may only present itself under some pretty esoteric circumstances. As the tab detection problem as originally posted has moved on slightly, is it worth bringing in #2136 to add some additional viewpoints? |
I'm a bit confused about this issue. Is there some bugfix in v6.50 that can't be rolled back? For me as well v6.49 works great, except minimized/hidden windows (x64 macOS Catalina) |
@probablykasper the complexity here is that we need different internal implementations for the various macOS versions, because Apple has changed their undocumented APIs in very subtle ways with the last 2 releases. So we need 3 implementations, and i'm no longer able to test them to develop them because on my new macbook, I can no longer run my collection of VMs i was using to test the app on various macOS versions. |
I see, thanks for explaining |
# [6.61.0](v6.60.0...v6.61.0) (2023-07-12) ### Bug Fixes * better identify tabs on macos versions older than 13 ([3147a69](3147a69)), closes [#2017](#2017) * don't show empty color-slurp windows ([01b3a42](01b3a42)) ### Features * improve german localization ([1084d87](1084d87)) * improve support for crossover windows ([f9f1c19](f9f1c19)) * improve support for scrcpy always-on-top windows ([0673381](0673381)) * show the ui by right-clicking the menubar icon (closes [#2647](#2647)) ([63502d5](63502d5))
Just noticed this in the changelog so I've finally updated from 6.49. Wanted to follow up and say thanks for implementing - seems to have fixed tab detection for unminimized / unhidden apps, which works for my workflow 👍. |
I'm glad it helped! All the credit goes to @decodism's great work 🙇♂️ |
Describe the bug
When the (1) "Show Standard tabs as windows" option is disabled in the Appearance options, and (2) the user has elected to show "Hidden windows" from the Control options, AltTab ignores the first option. In other words, it still shows standard tabs as windows. To be clear, this only occurs when the window is hidden. Otherwise, AltTab performs as expected, and only shows windows.
Screenshots / video
When the window isn't hidden, AltTab performs exactly as it should—displaying only the window. This is illustrated in the screenshot below using a Finder window with two tabs.
However, once you hide the window, AltTab will now show both of Finder's tabs as windows—effectively ignoring the disabled option to "Show Standard tabs as windows".
Steps to reproduce the bug
The text was updated successfully, but these errors were encountered: