Skip to content
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

App Icons: Unwanted new windows on App focus #3951

Closed
hiltbru opened this issue Dec 8, 2024 · 3 comments
Closed

App Icons: Unwanted new windows on App focus #3951

hiltbru opened this issue Dec 8, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@hiltbru
Copy link

hiltbru commented Dec 8, 2024

Hi,

When using the “App Icons” appearance with “Show in switcher: Applications” enabled, some apps act a little annoying when switching to them with Alt+Tab.

For example:

  • In Apple Mail, switching with Alt+Tab always opens the Message View window if it’s not already open.
  • This also happens in apps like Notes, QuickTime, or anything that spawns a new window when clicked in the dock.

It seems like Alt+Tab is behaving like clicking an app in the dock, rather than how macOS’s default Command+Tab works (just focusing the app without creating new windows).

It would be great if AltTab could more closely match the default macOS behavior here, with the added benefit of the great customization options it already offers.

I’ve attached a quick video to show the difference: (1st: default, 2nd: Alt Tab)

AltTab-WindowActivationBug.mp4
@hiltbru hiltbru added the enhancement New feature or request label Dec 8, 2024
@lwouis
Copy link
Owner

lwouis commented Dec 8, 2024

Hi,

Behind the scenes, when in Show: applications mode, we select a "main window". Thus, when the user focuses an App Icon, there are 3 behaviors we could have:

  1. Activate the app. This is what the native command+tab does. It's very neutral. If the app has windows, it brings all of them to the foreground. If it doesn't have windows, it will not spawn. The app is active though (e.g. its name shows in the menubar)
  2. Launch the app. This is what AltTab does today. This is also what clicking an app on the Dock does. It's less neutral as it sends the app a request to "launch". Each app can implement it differently. Many apps will bring all windows to the foreground if they have windows, and spawn a new window if there are none. It's up to each app to implement though, so there are variations to what happens.
  3. Focus the "main" window of the app. This is something none of the native macOS systems use. We can do it though, since we act at the window level.

We used to use method 1 in the past. However, users complained that it's not very useful to activate an app. They want a new window if there is none. They don't want to switch then have to command+N afterwards. For Finder typically.

When we released v7, we considered moving to method 3. However, we didn't because it could be a bit surprising. Especially in App Icons Style, people would expect the same the whole app to be activated, like the native command+tab does.

So we went with method 2, as it seemed it would satisfy the most users. We also want to avoid adding another preference to pick behavior here. The whole purpose of v7 was to #351.

Thank you 🙇

@hiltbru
Copy link
Author

hiltbru commented Dec 8, 2024

Thanks for the explanation, didn't realize the history of this. While I prefer method 1, I do understand the rationale and importance of simplifying UI.

One idea that comes to mind is a sort of compromise - there's a setting in AltTab to Hide apps with no open windows, under the "Customize style" menu. If this is checked, then even with the Show: applications setting toggled on, you'll never be shown App icons that don't already have a window. This is how I personally use AltTab.

If Hide apps with no open windows is checked, I don't see any benefit to "Launch" apps, as the user will know, with certainty, that an app icon represents an open window. In these circumstances, could the logic be changed to follow either methods 1 or 3?

This might have the drawback of potentially adding some complexity and, if explained, boilerplate to the settings UI, but generally I don't see a scenario where somebody has both of these settings toggled on and want method 2, meaning that I don't think this would necessarily need to be mentioned anywhere in the UI - you could keep things looking as they are right now.

Could be a solution?

@lwouis
Copy link
Owner

lwouis commented Dec 8, 2024

Thank you for your message

I think what you say makes sense.

We went with launching instead of activating apps because we believed that Apple's way of activating an app and having nothing happen was not working with most users. I suspect most users don't understand "the app is running but it has no windows". I believe this is why clicking on the Dock launches instead of activating. The Dock is probably what most users use. Not the command+tab switcher. It's still surprising that Apple has kept the switcher activate and not launch.

Following this logic, we should probably launch only apps with no open window. For app with existing open window, we could simply activate them since we know it will bring their window(s) forward guaranteed.

I'll change this in the next release 👍

Thank you for taking the time to discuss this in details 🙇

@lwouis lwouis reopened this Dec 8, 2024
@lwouis lwouis closed this as completed in cb191d6 Dec 9, 2024
github-actions bot pushed a commit that referenced this issue Dec 9, 2024
# [7.11.0](v7.10.0...v7.11.0) (2024-12-09)

### Bug Fixes

* always show a window in show:apps mode (closes [#3950](#3950)) ([ac70fcc](ac70fcc))

### Features

* decrease shortcuts from 5 to 3 ([d65f220](d65f220))
* improve chinese localization ([764e0f3](764e0f3))
* improve focus in show:apps mode (closes [#3951](#3951)) ([cb191d6](cb191d6))
* support 3 or 4 finger swipes to use the app (closes [#730](#730)) ([903e758](903e758))
* switcher will now show in "show desktop" mode (closes [#783](#783)) ([9b85f00](9b85f00))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants