-
-
Notifications
You must be signed in to change notification settings - Fork 354
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
List window-less apps #397
Comments
Hi @SoPat712! Thanks for sharing this idea! It would be a new preferenceThis 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 concernsHow 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 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. |
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. |
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 |
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? |
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 ***@***.***> 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
<#397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHHRZKTWQVWJHVA7AF6MUO3R4OOWTANCNFSM4OSCJ4PA>
.
|
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? |
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 ***@***.***> 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
<#397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHHRZKRJFTC7D5OE5DIMVPLR4OTP7ANCNFSM4OSCJ4PA>
.
|
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 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 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. |
@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.
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. |
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. |
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. |
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. |
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 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. |
@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. |
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 🙏 |
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 |
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. |
No it's universal. Any app, visible in the Dock, running, without open windows, will show in AltTab. Terminal and Finders were just examples.
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: |
Yeah, that one seems totally appropriate. |
I agree, the icon looks pretty appropriate for the task at hand. |
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. |
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. |
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? |
Also, just a recommendation for an enhancement feature, it would be cool if you could select an open app window, and have alt-tab find the bundle id and automatically place it into the blacklist. That would make it much easier to block some sub windows that interact poorly with alt-tab. I think alt-tab does a much better job at finding the bundle id for those apps than we would have at finding them. |
I've been using
in Terminal. eg: lsappinfo info -only bundleid Finder returns "CFBundleIdentifier"="com.apple.finder". |
Oh thanks @frypf ! |
@lwouis The latest build apparently seems to be working for me? I don't know what changes you made, but they work like a charm. Now, the glitch I was talking about only happened once, and after that one time, it never happened again! Thanks for the great work on that bug! That reminds me that I need to start learning Swift haha. Quick question: Do you use AppCode or XCode for development? Any reason why one is better than the other? |
There is already a ticket for this: #539
I use AppCode before I love IntelliJ and have been using it for years. I can reuse all my knowledge of the idea in there. XCode in contrast is its own universe. It crashes a lot in my experience like investigating the view hierarchy during debug straight up crashes every single time I use it after I unfold a few nodes in the tree. Auto-complete, source-control management, navigation, search - all of these I find superior on AppCode. However AppCode is dependent on XCode to function, and some things I use XCode to check/learn/set regularly. It's a bad IDE overall. Also there is this whole joke about 1 range of macOS versions is tied to 1 range of XCode versions which are tied to 1 range of target iOS/macOS versions. Not user-friendly, not portable, hard to deal with for CI, etc, etc. You can read more on the dumpsterfire that is Apple developer ecosystem on the contributing page. |
Omg I found that the font issue was not some complex OpenType support or anything. I forgot a simple line. Oh well, I can't get back the hours of research, but at least we are moving forwards 👍 |
Glad you found it, I was racking my own brains and limited knowledge - didn't mean to leave you hanging, but was holding off while you ironed out the issue for @SoPat712. The only alternative I could find was to load an SVG within a WKWebView, which works but is probably not ideal. |
@SoPat712 I feel more confident in releasing now. The only outstanding issue is what you showed here: #397 (comment) Could you please test this build? If it's working for you then i'll release. |
With all the hate on electron these days because of its high resource consumption and poor performance, I found it quite humorous that you mention using a webview! As a fun anecdote, before I went on to use Swift, I tried to code AltTab using Electron, as they have an API to stream open window contents as video streams. I didn't know at the time the insane depths of macOS window management, so I gave up when electron couldn't show me the screenshots of minimized windows, or focusing windows on other Spaces. I didn't know yet that I would need to learn about macOS retro-engineered private APIs in order to do such basic functionality. Anyway just so you realize what this solution would entail:
I wrote this just for the fun of showing the reality of these kind of funky solutions. Maybe it wouldn't even be that bad. I've learned to anticipate the worse in the Apple ecosystem though lol |
Yep, I've only done some very limited playing around with it myself and found the same issues leading to a very obvious delay while it loads. I was pretty sure you'd have already dismissed it, but you'd asked me a specific question and I don't like just offering nothing. Spot the noob 😂 |
I've been testing the local build you've given me, and all seems to working well. I think it's time to release it after a lot of work on your end @lwouis ! Again, I think all of us would like to thank you for the amount of time you've put into creating this extraordinarily useful app! I think I can say once and for all, that Apple is now behind you in terms of Cmd+Tab! |
There is one thing, though. I seem to have somehow opened a Finder window, even though it's in my blocklist. I'm not sure how, but it's also not showing up, which means it's working, just that the app is checking the blocklist after it get all the windows and apps that exist. |
Oops I hit the wrong button, there really needs to be a confirmation for closing issues! |
@SoPat712 I'm sorry I don't understand the situation you're describing. I tried to add Could you please share a video of the issue to clarify the behavior you're seeing? |
It's unreproducable. I Cmd+tabbed really quickly, and somehow managed to open a finder window even though it's in my blocklist. This isn't something you should be worried about, because I think it was 100% a 1 time thing. I think the problem is that the blocklist is checked after the apps that are open are found. Therefore by me Cmd+tabbing very quickly, I was able to focus finder before it got removed from the array of apps or whatever. Either way, it's not a problem. One question: What version are you planning to make this release? This is a massive update, so it should probably be a major version switch! |
I was able to reproduce the issue by blacklisting Notes, then running this in the Terminal:
I use semantic-release so versioning is decided automatically. I merge a PR and it runs CI > CD, and done. No manual step is involved to release 👍 |
# [6.2.0](v6.1.0...v6.2.0) (2020-09-04) ### Bug Fixes * apps would not quit properly sometimes (regression from 10b2c71) ([41384d9](41384d9)) * avoid random delay after releasing shortcut (closes [#563](#563)) ([cbc4c39](cbc4c39)) * crash on launch if the user didn't have sf symbols font ([58e9026](58e9026)) * focused wrong window in rare scenario ([66820a1](66820a1)) * issue when selecting windowless app from fullscreen window ([657c9e5](657c9e5)) * smoother behavior when summoned during a space transition ([e6ded6c](e6ded6c)) * thumbnail sizes could be wrong when switching between screens ([e13a263](e13a263)) * triggering alt-tab during space transition failed (closes [#566](#566)) ([d66d788](d66d788)) * windowless apps would rarely show despite the blacklist ([355225b](355225b)) * workaround a quick in photoshop (closes [#571](#571)) ([7218418](7218418)) ### Features * allow per-shortcut release action preference (closes [#573](#573)) ([2a9c33b](2a9c33b)) * first blacklist can now match prefixes instead of full ids ([10693d0](10693d0)) * new preference to hide thumbnails (closes [#384](#384)) ([877c93c](877c93c)) * show about item in menubar menu (closes [#574](#574)) ([78d1d8f](78d1d8f)) * show apps with no open window (closes [#397](#397)) ([f0fa02c](f0fa02c)) * update fi, hu, nl, pl, ru, zn-tw localizations ([df3010a](df3010a)) * update japanese and korean localizations ([2a2368d](2a2368d)) ### Performance Improvements * add preferences cache to reduce app latency by a few ms ([17863b5](17863b5)) * menubar takes a few frame less to compute ([3b7350f](3b7350f)) * reduce image assets size even further using optimage ([63d8545](63d8545))
Thanks for all the work on this, @lwouis ! It's a major enhancement. |
Just found that Zoom does not show up in Alt-Tab. Odd. |
@Stokestack could you please open a new ticket for this Zoom issue? |
Sure. I just launched Zoom and found that it does show up when you're simply on the log-in screen (not in an active session). I have a meeting tomorrow, so I'll verify this again. |
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.
The text was updated successfully, but these errors were encountered: