List window-less apps

[SoPat712]

Is your feature suggestion related to a problem? Please describe. Sometimes i open sublime text, or preview, and use CMD+W to close the image or tab, but then I forget to shut it down. That means that I'm wasting ram or processing power on something that i'm not even using.

Describe the solution you'd like Copy Mac-OS' approach to just putting every app there, regardless of whether there is a window open.

Describe alternatives you've considered I've tried switching back to regular Mac-OS CMD+Tab, but it just isn't as convenient as alt-tab. I'd love for this feature to be implemented.

[lwouis]

Hi @SoPat712! Thanks for sharing this idea!

It would be a new preference

This is an interesting idea. It reminds me a bit of #354. It would have to be a preference for sure, as some users will want to keep some apps open, but don't want them to pollute the window list with an "app window". For example users of heavy apps like Photoshop, AfterEffects, AutoCAD, may keep the app open to avoid the long load time when they need to load something in the app.

UI/UX concerns

How the UI would look like? Maybe a small rectangle, with the app icon maximized, in place of the thumbnail; and the title would be the app name instead of the window title?

Another concern is the UX. Focusing this "app rectangle" and releasing the shortcut would put the focus on the app, or do nothing? The built-in app switcher just focuses the app, but interestingly, if you instead click on the Dock icon of a window-less app, it usually focuses it and opens a new window for it. Which one should we do here?

What about window-specific shortcuts such as alt+w to close or alt+m to minimize. They would silently do nothing?

I'm worried the user could get confused by the UI, and not necessarily understand that this rectangle represent a window-less app. They may think there is a problem with AltTab since it shows a window without a thumbnail, and focusing it doesn't show the window.

[SoPat712]

Hi @lwouis , you are correct about the fact that it would need to be a preference. I think the smartest way to display it would be to have one box with the app icons. I'll draw something up tomorrow.

[SoPat712]

this is something i just drew up. It should stay out of our way, but should remind us that they’re still there. Menubar apps, or other already out of the way apps shouldn’t be shown there though.

[SoPat712]

Another concern is the UX. Focusing this "app rectangle" and releasing the shortcut would put the focus on the app, or do nothing? The built-in app switcher just focuses the app, but interestingly, if you instead click on the Dock icon of a window-less app, it usually focuses it and opens a new window for it. Which one should we do here?

What about window-specific shortcuts such as alt+w to close or alt+m to minimize. They would silently do nothing?

You mentioned the actions taken when the app is selected. There would in a perfect world be a preference setting in which the user could choose to never focus these apps. These apps should only either be left open, or be quit with alt+q. I feel like that is the most intuitive in this scenario, as having smaller icons clearly differentiates the app from the others

[Stokestack]

I consider this to be a deal-breaker for Alt-Tab unfortunately, especially in the case of Finder. Finder is always running, but I have often closed all of its windows. Since it's missing from Alt-Tab, I can't even activate it and then press Command-N. Apple's failure to restore minimized windows is tedious, but with Alt-Tab I can't even access some applications with the keyboard.

To address this, Alt-Tab needs to offer the display of windowless apps and the option to issue a Command-N ("new window") to them when selected. That would be another big functional bonus, which is almost as important as restoring minimized apps.

As far as the UI of the application list is concerned, why not just show the application's icon?

[SoPat712]

Yeah the way it works though is that once the app is switched, all of the apps commands automatically work. The window less apps part I agree with, but the cmd plus n is no work on their part.

On Sun, Jul 19, 2020, 9:46 PM G notifications@github.com wrote:

I consider this to be a deal-breaker for Alt-Tab unfortunately, especially in the case of Finder. Finder is always running, but I have often closed all of its windows. Since it's missing from Alt-Tab, I can't even activate it and then press Command-N.

To address this, Alt-Tab needs to offer the display of windowless apps AND the option to issue a Command-N to them when selected.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lwouis/alt-tab-macos/issues/397#issuecomment-660753538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHHRZKTWQVWJHVA7AF6MUO3R4OOWTANCNFSM4OSCJ4PA .

[Stokestack]

Hi SoPat,

Not sure I understand your remark. Do you mean that once the application is selected, Alt-Tab has no way to communicate with it and issue a "new window" command?

[SoPat712]

Alt tab won't need to. Once the app is switched, then you can just communicate with it via keyboard shortcuts of the app e.g it will show up on your menu bar to fully control.

On Sun, Jul 19, 2020, 10:27 PM G notifications@github.com wrote:

Hi SoPat,

Not sure I understand your remark. Do you mean that once the application is selected, Alt-Tab has no way to communicate with it and issue a "new window" command?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lwouis/alt-tab-macos/issues/397#issuecomment-660764693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHHRZKRJFTC7D5OE5DIMVPLR4OTP7ANCNFSM4OSCJ4PA .

[Stokestack]

I understand that, but it would be nice to have Alt-Tab eliminate the extra step of creating a window, the same way it automatically restores minimized apps.

[lwouis]

This ticket is overlapping with #354. To recap what I understand from both discussions:

Some users would like to have AltTab open new windows on apps that are currently running, but have no window. Finder is a special case as it is always running and shouldn't be quit, but the case could be made for any app which has no windows open.

UI would be to show the app icon instead of the window thumbnail, in a rectangle similar to the windows rectangle. If the user select that rectangle, they can't do window-specific shortcuts (minimize window, close window, etc). However, they can do app-specific shortcuts (quit app, hide app, etc).

Moreover, if the user focuses the rectangle, it would either focus the app, then the user would hit cmd+n or use the mouse to open a new window. That's what the built-in app switcher does. Alternatively, focusing the rectangle could directly focus the app and open a new window. I'm not sure that second behavior can work universally. It may not be technically possible to do that for some apps. Maybe some apps don't have "New window" shortcut. Also there is no API to open a new window because that's specific to the business each app is doing. The only thing that AltTab could do maybe, is send the cmd+n shortcut to the the app after focusing it. In some apps it may not open a new window, if they have set another action to that shortcut.

Another issue with this idea is that "running app without an open window" is a non-trivial designation. That clearly should include apps visible in the Dock, but should it also include apps that only have a menubar presence? What about apps that don't show anywhere, like AltTab itself if you check the box in the preferences?

To give you an idea, on the average system, AltTab is following around 50 apps, in case they generate windows. This covers very visible apps like Skype in the Dock, but also menubar apps, and even system daemons like imagine when you get a phone call on your mac. Some Apple daemon is routing that call to your computer, and popping up a window. Should we display that app as an app without open windows? Do you see the problem with there being around 50 of those? We could only show Dock-visible apps in the listing, but that may be strange if you rely on a menubar-visible app, and don't see it in the list.

[SoPat712]

@lwouis I understand the issue with AltTab following so many apps, but menu-bar apps are strictly designed to not create extra windows. I think the solution that both of us would like is to be able to pin apps to the 4 areas depicted below.

I for example would probably pin pathfinder, clipto, and some other usually windowless but always running apps, as I use them all very often.

The point isn't to supplement functionality not given by you, this enhancement is just extra features that reduces our reliance on the dock provided by Mac, and allows us to keep our hands on our keyboard.

I think an easy way to fix this would just be to let users pin their own applications to the quadrants above. I also do understand it's a lot of work, so please do inform me if this is an unrealistic goal.

@StokeStack

I understand that, but it would be nice to have Alt-Tab eliminate the extra step of creating a window, the same way it automatically restores minimized apps.

This functionality is already in alt-tab. If i'm not mistaken, it just takes certain commands, and forwards them over to the app as soon as the app switch is triggered.

[Stokestack]

Thanks for that thorough summary, lwouis.

Actually, I don't really want to pin anything anywhere; so I'll leave that up to you guys (although I prefer not to be forced to use pinning). To solve the problem of "too many apps" or daemons, I think we should use whatever criteria Apple uses for its Command-Tab display. I realize that Alt-Tab provides the additional display of separate windows; but the filtering of applications themselves should match Apple's, which seems to work fine.

My entire motivation for installing Alt-Tab was Apple's refusal to restore minimized windows with Command-Tab; I see the option of creating a new window for a currently-windowless app as a very similar function: Make the app usable right away if you Alt-Tab to it.

[SoPat712]

Apple has millions of dollars in developing budget. This is an individual project made on someones spare time. The easiest method(pinning apps) is not the most convenient, I agree, but Apple has significantly higher budget, and more reason to make their software the best as they possibly can. Personally, I have no problem with pinning, and it seems like the best solution for most people.

[Stokestack]

Am I missing something? I'm using Alt-Tab right now and don't see any "pinning," so I'm fine with that. I'm not asking for additional UI work in that regard. If there's pinning available right now, and I'm not forced to use it, all good. Maybe I'll try it and like it later.

[lwouis]

I understand the issue with AltTab following so many apps, but menu-bar apps are strictly designed to not create extra windows.

This is incorrect. AltTab itself is an example of a menubar app that can spawn windows: the preference window, the feedback window, the permissions window. These properly show in AltTab UI. More information here (scratches the surface, but gives an idea).

pinning

Pinning goes into the territory of launchers. You already have a billion apps doing this, including macOS own Launchpad (which is the one i use because of its speed), and Spotlight.

I don't think I want to go into launcher territory. It's just a huge space with already great offer. However, focusing already running apps could be argued to be a different thing, as if Finder is already running for example, a launcher won't help focus it. This highlights a gap in AltTab, which I find interesting to fill.

I will investigate showing Dock-visible apps in the launcher as another window, but with the app icon instead of the window screenshot.

[zzamboni]

@lwouis thanks for Alt-Tab! I started using it today and find it very useful.

It would be very nice to be able to switch to apps without windows. I think the best starting point would be to emulate the native Cmd-Tab: i.e. include only Dock-visible apps in the switcher. This is the only thing I miss from my normal workflow.

[lwouis]

Hey everyone! I've been working on this ticket, and made good progress. Now I'm looking for opinions about some behaviors and UI considerations.

Here is a showcase of the current state of the feature in action.

Please share your thoughts 🙏

[SoPat712]

Firstly, I love the feature where it creates a new window. There are plenty of times where I'm utilizing an iTerm window and close the window, but don't quit the app. The feature where it creates a new window when I select that in Alt-Tab is honestly genius, and I can't believe that Apple hasn't already implemented that feature.

I have some questions though. Will this only work for certain predefined apps that you would have to set? I saw you do it in /Applications/Utilities/Terminal.app, but I use /Applications/iTerm.app, which is another terminal application, as you probably know. Basically, my question is, would this feature also work for external terminals, or would it just be preset apps. Would this also happen in Firefox, for example I close the window, but don't want to quit Firefox, and thus leave it open. If I select Firefox, would it know to create a new window?

Secondly, Could you possibly expand the app icon in the final version to fit the whole box. The transparent background looks awkward and out of place, and the UI design is something that I think needs to change before releasing the version.

Lets discuss the subject of where the window should be placed. Personally, I'm a firm believer that all new windows should be placed directly in the center of the main monitor. I use BetterSnapTool to resize Windows, and while it doesn't matter all that much for me, I still feel that it would be more convenient to just center the app window, instead of creating them in the place of the last terminal window I closed. While closing terminal windows, I don't close them in a specific order, and that would just be unnecessary in my opinion to place them in the essentially randomly selected final window closed location.

The quitting feature you got right. You should be able to quit all apps, and you should only be able to close, hide, and minimize open apps.

The kill finder feature was done through activity monitor, and it was never a "kill" option. I think that finder essentially always runs in the background, just like the dock process on MacOS, because those apps both manage more than their name suggests.

For closed apps, but not quit apps, like terminal and finder at 8:20 in the video, I think the apps should just be ordered from oldest closed to latest closed, so exactly the way you have it now. I just don't think the semi-transparent background looks very good, and I'm not sure how to make it look better. The circle with the cross through it is already the symbol used for hidden apps, and symbol like this might look a bit better

These are just suggestions, and I don't know how it would really look in the correct position, but in the end, it is really up to you how you choose to navigate these issues.

However, I really did enjoy this design I drew up about a month and a half ago.

I thought that it pretty well showed how the apps were just going to be launched, and not just focused, and the upside is that there is no icon needed to fill up blank space

[Stokestack]

Thanks for taking the time to make that video, @lwouis !

I like everything you've proposed, and I think using the big application icon for apps that currently lack a window is a good idea. In fact, I prefer just having a giant icon (like Apple's normal Command-Tab display) instead of the application thumbnail for all running apps, but I realize that this doesn't let you distinguish between multiple windows of the same app.

An X or a slash to me means "forbidden" or "disabled," and thus I think it would be perplexing to the user if you used it for windowless apps.

I also agree with putting windowless applications at the end. Usually if I've closed an application's window, I'm not expecting to bounce back and forth between it and the app I was using before it. In fact, it would be pretty annoying to accidentally create a new window and have to close it simply because I thought I was going to toggle between the next two running apps.

[lwouis]

Will this only work for certain predefined apps

No it's universal. Any app, visible in the Dock, running, without open windows, will show in AltTab. Terminal and Finders were just examples.

it would be pretty annoying to accidentally create a new window and have to close it simply because I thought I was going to toggle between the next two running apps.

This is a great argument! I realize now that it will be the mindset for most users.

---

Regarding the UI, keep in mind that whatever solution is picked needs to scale up and down. People can customize AltTab to have huge thumbnails, if they have 4k monitors for example.

Thus using the app icon has limitations. Some apps will not have big icons that look good scaled-up. It may also be a bit unclear what focusing the icon does.

I'm trying to use SF Symbols as much as possible, as it's free vector assets. macOS doesn't support SVG, but it support fonts, so font-icons are a great way to have infinitely scalable visuals in a macOS app. I found this icon that I think could be a good visual:

[Stokestack]

Yeah, that one seems totally appropriate.

[SoPat712]

I agree, the icon looks pretty appropriate for the task at hand.

[frypf]

I may be going against the grain here, but I actually liked the look of what you had in the video with no thumbnail and just the empty space. To me at least, that combined with placing windowless apps consistently at the end of the list tells me everything I need to know - I feel that putting an icon in the space might look incongruous set against the other window thumbnails.

Definitely like the idea of creating a new window when selecting a windowless app, although I'm not sure I'd want it to be placed anywhere specific - other than on the same space as it was previously. Beyond that, this starts getting into window management territory and I already use Yabai for that. Introducing that extra bit of functionality may end up creating unforeseen conflicts.

Other than that, agree that this should just be aimed at apps with a dock icon, and the quit shortcut is all that's needed. As to having the other shortcuts fail silently, this doesn't seem an issue as closing a non-existent window or hiding a windowless app doesn't make any difference to usability really - although it does raise an interesting related request. Would it be possible to place hidden apps at the end of the list (but before the windowless apps) instead of retaining their current chronological position? This ties in with what @Stokestack says about switching back and forth with windowless apps. I know it's not emulating the MacOS default behaviour, but it'd be tons more useful as logically if I'm hiding an app I'd expect it to not then be the thing I immediately want to switch to next.

[Stokestack]

Would it be possible to place hidden apps at the end of the list (but before the windowless apps)

Seems logical to me.

As far as the icon goes, I already find that the efficiency of Alt-Tab is reduced by having to peer carefully at the tiny icons; but I understand the need to show screen thumbnails for apps with multiple windows. But if there's no window to show, I think we can reduce the mental processing required by having a nice big icon.

[frypf]

I was talking more in reference to the suggested generic "add window" icon that @lwouis referenced at the end of his last post. For me, if there's no window to show and there's no window in the switcher then that's as I'd expect, though I can definitely see the usefulness of having the specific app icon as per the original MacOS app switcher - particularly when working with a large number of windows and apps.

However I'm still not sure how this would work with the potential doubling up on the app icon for those who already have the top left corner icon set quite large. I definitely tend to prefer a minimalist approach to the amount of "stuff" I can see onscreen, hence my over-reliance on separate spaces for apps and things like window management apps, despite Apple seemingly decreasing their interest and investiture in these concepts over successive MacOS versions. UI is certainly a minefield of conflicting requirements 🤷‍♂️

As to the scaling issue could there be a max size equal to the 1024px that most Mac apps use these days? It shouldn't be this app's duty to make other people's poor design look shiny and new, although I appreciate that end-users may wrongly associate the problem with AltTab, rather than with the app they're switching to having a bad icon to start with. Everything else about this app is so nice and polished, and I can fully understand @lwouis wanting to maintain that going forward. On the other hand, surely those with large enough displays would already experience and be aware of this problem and the reasons behind it?

[Stokestack]

Oh yeah, I forgot about the "add window" icon. I strongly prefer that over an empty space, because it tells the user exactly what's going to happen.

[lwouis]

I've finished working on this ticket. There were other interactions with this features that I discovered:

• Almost all preferences in that list interact with the feature:
• Blacklists
• Spaces icon should display the asterisk for these windowless apps since apps exist in all spaces

Here is a local build. Could you please help me test it before I release it? 🙇‍♂️

[frypf]

Just tried, it apparently loaded ok but unfortunately wouldn't show either the switcher or prefs without crashing/exiting.

Clarification: clicking "Preferences" in the menu bar did nothing, clicking "Show" crashed/exited. The keyboard shortcut just brought up the default MacOS switcher. Think I sent a crash report (possibly worth adding some sort of confirmation for that via notification centre or a modal?). It's entirely possible I'm being a noob in some way.

[SoPat712]

I also sent a crash report. The local build did not work for me either. I just downdated the app back to 6.1.0 and it's working again. Not sure what happened there haha.

[lwouis]

Here is the stacktrace of your crash:

MAIN THREAD CRASHED

AltTab
AltTab.App.hideUi() -> () App.swift:116
AltTab
AltTab.App.showUiOrCycleSelection(Swift.Int) -> () App.swift:223
AltTab
partial apply forwarder for closure #1 () -> () in AltTab.App.showUi() -> () App.swift:166

I don't understand at all. This path through App.swift is the exact same as in 6.1.0. I have not touched App.swift in the local build. This path is:

• Click "Show" in the menubar
• User either has 0 window open (I see it's not the case in the debug profile), or Expose is open
• UI hides

So at step 2, how come it's hiding the UI. You had windows, so it's the only explanation is that you were activating Expose / MissionControl.

Even doing that I can't reproduce. That's frustrating. I don't get what's happening on your machines, and I don't know how to dig deeper.

Note: I received 2 crash reports, but both from the same user (a mac mini 2018 user).

[frypf]

Still no luck. I tried killing Yabai, restarting the Dock and even the whole machine but each time the same scenario as before. I noticed the modification date of the new build's app file states 02:59 tomorrow, so I even tried changing my system date to match on the off chance, but nope.

I definitely wasn't using Expose/Mission Control at the time - I was cautious after the restart not to even activate it before trying the new build.

[Stokestack]

Similar results here. The prefs pane won't appear, and the app doesn't appear to be working; I get the standard Apple Command-Tab UI. After the preferences wouldn't appear, I selected "Show" from the Alt-Tab menu and it immediately crashed. Maybe that's a help; I sent the report.

[lwouis]

I'm really confused as to why this is happening. Another hypothesis I have is that the PreferencesWindow is not even instantiated, thus the crash on App.swift#116. But how would that be possible. The init happens early during the launch, and is guaranteed by the language.

I still only see crash reports from the macmini 2018 in AppCenter. Other people who had it crash, could you tell me on which macOS version you are? Also could you click in the menubar the "Send feedback" option, and share what happens if you do that?

[zzamboni]

I see the same behavior as reported by @Stokestack with the test build. I am on macOS 10.15.6.

When I select "Send feedback" from the menu, nothing happens - no window but also no crash. I do get the crash consistently if I select "Show" from the menu. I have sent the crash report every time.

[lwouis]

Ok then it seems that there is an issue where no window is initialized. The Feedback window and preference windows have a check to avoid crashing if they are nil, but the main window is supposed to never be nil, so asking to show it crashes.

I don't see how these windows can be nil. Could you please let me know if this build acts differently? It contains #384 implementation on top of this ticket. Perhaps the issue is magically gone?

If it still crashes, could you please share with me the results of defaults read com.lwouis.alt-tab-macos, as well as grab the Crash Report in Console.app (go in the sidebar > Crash Reports > Search "AltTab" > right click on each row > "Reveal in finder" > attach to your comment here)

[foss-]

Latest test build cannot be opened, even via right-click option.

[lwouis]

Sorry @foss-, I think I shared a Debug build. Here is a Release build

[zzamboni]

@lwouis first of all, thanks for all your work working on this! AltTab is already excellent as it is, so your work on further improving it is much appreciated.

The latest build behaves the same as before: I get the built-in macOS launcher, selecting "Show" from the menubar causes a crash. I've sent a couple of crash reports from it.

[foss-]

AltTab starts and shows in activity monitor, but I can't tab through open apps. It does not show its UI on macOS 10.15.6, supplement update. I do not see a crash though or no indication for a crash / hang in activity monitor.

[lwouis]

@zzamboni thanks for the encouraging words! As I've said, I only received crash reports from a mac mini user. They are on 10.14.6 as well, and you said you're on 10.15.6, thus I conclude that your crash reports never reached AppCenter.

@zzamboni @foss- Could you please follow the steps I listed above? @foss- try clicking the menubar icon then "Show". It will probably crash as it does for everyone else (except me). Then you can share the crash report and preferences

[foss-]

My problem is: I had played with alttab and opted to not show the menubar icon. Was trying to understand how to invoke alttab preferences. But maybe that not working is related? So this is a bit of a catch 22 I guess.

[lwouis]

@foss- yes, you would have to launch the public release (e.g. 6.1.0), re-enable the menubar icon. Then you can quit it, and launch the local build I shared

[foss-]

Requested terminal output: https://bin.disroot.org/?080251cdfdc792a9#GCQqZgYQC2yLcrXGcve3z2dtQj8fpDxQGoxyap6qgiQk

Although I am not seeing a crash I cannot open AltTab preferences.

[lwouis]

@foss- did you try selecting "Show" from the menubar? That's what's causing the crash for others (see what other people wrote above)

[foss-]

Ah sorry didn't read the entire thread. Can confirm the crash. Crash log: https://bin.disroot.org/?7f03e22e8b036165#Bfw5t1NFgwWNWjUmiadFaqvLRMxQLgEhUZdidjtYXsEo And requested terminal output: https://bin.disroot.org/?086b16b67cb256fd#4bAnUfaWAz3TvVhErfwW85xMUzWBqsFYxyYnwAYYv3tw

[frypf]

Same again for me with the new version. I'm pretty sure the crash reports you've been successfully getting are mine, although I'm wondering if it makes a difference if they're sent when I try reopening the test build versus reopening the original 6.1.0. The dialog asking to send the report shows up for both. In any case, here's the other data as well:

Terminal data crash log

[lwouis]

All these crashes happen at the same spot. I have no clue how this is happening and why it doesn't on my local machine

[lwouis]

@foss- was kind enough to let me debug on his computer remotely. We found the root cause of these crashes: there is an issue with the new character from the SF Symbols font, used to represent an app without window. I'll work on a fix now, no need for further logs and crash reports 👍

[lwouis]

Here is a build that should work now. Please let me know about the feature in this ticket, and also #384 if you're interested.

Please share feedback before I release the next version 👍

[zzamboni]

The latest build works great for me: