Closed alt-tab-macos-bot closed 2 years ago
...just a small correction to the above:
Hi @rxhfcy! Thank you for sharing this feedback!
When I first implemented AltTab, i copied Windows 10 UX very closely. The shortcuts were working exactly as you describe (see #2 and #10 last year). I was also used to these from Windows, so I thought these were great UX.
Then later, some users brought very good points about why this isn't the best UX when you actually think about it.
Could you please read this discussion i linked? Hopefully you get convinced that the current approach is more ergonomic. When do you actually need to go to the "last window i focused in the past. That's not really a use-case, is it.
I'm open to continue this discussion if you think the current UX can be improved. I would ask you for strong, detailed, argumentation if that's the case though
You may also want to watch the video reply I did here.
@lwouis the video doesn't playback, it shows "An error occurred on the page: TypeError: Cannot read property 'catch' of undefined"
error.
Now that this thread has been brought to my attention, I second this particular request.
If both Windows and macOS native switchers can be summoned by the proverbial alt-shift-tab
, which can also toggle 'one window back' in your window/app order (and which IIRC some third party switchers can be configurable for exactly what that means - or am I thinking of browser tab switching options?), then I'd definitely vote for allowing AltTab to do this too. I rarely do this, but maybe I'll have a moment that makes me realise I actually do do it.
To switch backwards in your 'order' of windows you're working in, using shift
, vs. just alt-tab
can be helpful. So I give a not strong but definite 'second' to this request.
BTW, as an alt-tab connoisseur for 20+ years I observe this is already the best 'alt-tab' on any desktop platform (including Linux). I'm amazed.
Let me try to recap the rationale behind the current design:
alt-shift
is more ergonomic than alt-shift-tab
. Just look at your fingers when doing alt-shift-tab
. I have been doing it for a while so I'm used to it, but when other users said they literally can't do it, and prefer alt-shift
from HyperSwitch, I realized they are right, and it is indeed a better fingers motionalt-shift
as a default, it would be terrible to allow this shortcut to activate AltTab, as it is the stem of many apps shortcuts. It would unintentionally activate all the time. Thus I changed it to work only if AltTab was already opened (by pressing alt-tab
).I'm open to the conversation to improve the UX, but I would like to discuss arguments such a the ones I just shared. Comparing to other apps is not a strong argument in my eyes. There is always room for improvement, and I believe we just did that, but having a better shortcut than Windows 10 with alt-shift
.
@lwouis No one's suggesting alt-shift
(without a -tab
included) to toggle AltTab. The suggestion is for all three keys alt-shift-tab
to simply toggle the program and to select the oldest item in the GUI list.
Also, I see that 'last used' is a confusing word to use. 'Last used' (as in 'latest used') is actually the one second from the first item in the list - i.e. the one we were just in before the current window.
What we want alt-shift-tab
(/cmd-shift-tab
) to bring up and focus on is 'oldest used' or 'earliest used' - i.e. the oldest used window in the entire list.
Like I said, I don't and wouldn't do that often, but it does seem like default 'alt-tab' behaviour in Windows and macOS which doesn't detract from any other function and therefore I think it should be included.
I really hope you could just allow the Windows alt-tab behavior in this case too. You see, when I saw the tagline "AltTab brings the power of Windows alt-tab to macOS", I was amazed I'd found someone who is willing to do the sometimes thankless (thank you again for AltTab BTW, it's soooo close to perfection) task of implementing the Windows alt-tab experience to allow Windows users to use their existing alt-tab muscle memory unchanged in macOS. Because I know for a fact that some Windows users, myself including, use alt-shift-tab to open the window switcher for example to hunt for an open program they know they haven't used for a while.
I'm definitely not against configurability here, and I would kind of understand it if just the default settings were different than in Windows (ie. wrong IMHO), but I definitely think this is a valid bug, because it's something users can do with Windows alt-tab but currently can't with AltTab.
I understand you're doing this for free, on your free time, and that's incredibly generous of you, and you can freely do anything you want with this project, but I honestly think that everything a user can do with Windows alt-tab should also be possible in AltTab, otherwise lots of potential users could be confused and disappointed.
(Would someone please think of the muscle memory of possibly over a billion computer users, and the collective frustration and wasted time if they have to relearn anything, for any reason, valid or not! 😜)
What is your suggestion to enable this shortcut, while keeping people who dislike alt-shift-tab
for its bad ergonomics and want alt-shift
?
Actual mockup would be appreciated. You may want to look at the 2 or 3 designs I discussed back in the day. Note that the new design would need to accommodate the new Controls tab.
Thank you
^ @rxhfcy I think you want it more badly than me and I'm sure it's solvable, can you respond to that if poss?
First, I want to say that I did read the discussion and your reasoning above, and I get your point that some people have difficulty pressing the key combination. I'm just unconvinced that's the right default, because it breaks every current Windows users' existing muscle memory, so alt-shift sounds like an optional accessibility feature to me. But admittedly I have no idea how to implement this, other than the very hacky way of special casing the most common options: showing the window switcher when alt-shift-tab is pressed but obviously not showing it when only alt-shift is pressed.
In my mind, AltTab shows great potential and could (should) potentially be used by a lot of former Windows / Linux users who want window switching in macOS to work exactly like they are already used to. I think that would cover the vast majority of your potential users' needs, but then again it's human nature to believe your viewpoint is the right one, and it takes extra effort to even consider other people's viewpoints. But basically that's why I was trying to advocate you to copy Windows UX as closely as possible. Your call, of course.
I understand the argument that retro-compatibility with Windows UX is valuable.
Now in order to move forward, could you please reply to my message above?
Interesting discussion. I was also a bit confused when I first started using AltTab, but in the meantime I've gotten very used to using Shift while AltTab is showing to cycle backwards through windows.
To implement backward compatibility, how about adding a checkbox that indicates that the "Select previous window" key should also be recognized as an initial AltTab toggle? Something like this maybe:
The idea would be that, if this checkbox is enabled, Cmd-Shift-Tab would also trigger AltTab, but do the initial cycle to the "oldest" window in the list.
Side note: in the meantime I noticed that Cmd-Shift-Tab still brings up the macOS app switcher (since I've mapped AltTab to Cmd-Tab), which I find useful every once in a while, so I've started using it as a workaround when I need it.
@lwouis thanks for all your work on this great app - very much appreciated!
@zzamboni thanks for sharing this mockup!
I also planned on using a checkbox in earlier design mockups, however I think the UX is confusing. The "while open, press:" label is contradicted by the checkbox. Also the overall presentation with the "Hold A and press B to Select next window" above kind of breaks down.
How about moving it to the bottom, like the "Also select windows using" checkboxes? Something like "[ ] Also trigger AltTab with the 'Select previous window' shortcut".
I think i still prefer the checkbox next to the hotkey as the colocation clarifies the feature i believe.
Are you guys sure i should add this? Are you actually going to use this?
Well, my answer is yes I think you should (re)implement this (because alt-shift-tab is a part of the Windows alt-tab experience) and yes I would use it (I had to temporarily downgrade to an earlier version to avoid the pain of having to retrain my fingers: I use both Windows and macOS, and AltTab allows me to not have to care about which OS I happen to be using).
Me also, definitely. Sometimes if I have a small enough window list, I might want to 'go back one' in the alt-tab list. DEFINITELY. It's normal alt-tab behaviour.
I have not missed it, to be honest, but I think it would be nice for consistency.
@zzamboni please check out https://github.com/lwouis/alt-tab-macos/issues/541. We missed to realize that making the backwards-cycling shortcut a trigger shortcut means that we need to have 2 variants of it, same as the forwards-cycling one. Otherwise how would you backwards-cycle all apps or active app only?
Thus the checkbox UI is not a good solution to the problem. I think this brings us back to this mockup i made last month
I feel like I couldn't have done a worse job trying to convince you, but here goes again. I just don't understand your reasoning / priorities I guess. I honestly fail to see how the application can be described as "Windows alt-tab on macOS" when the keybindings don't even somewhat resemble the default Windows UX, regardless of what you personally might think about the ergonomics etc. Or at the very least the user should be able to fix the keys to match Windows UX. (This wasn't really meant to be passive (or active) aggressive, I'm just so frustrated, otherwise you're so close to perfection.)
For now, I'm forced to keep using version 4.6.0 which was so far the last version that could be configured to work anything like normal windows alt-tab does:
"alt"(=cmd) + tab: next window shift + "alt"(=cmd) + tab: previous window (this bug, the last window in the list if pressed first)
If this irritated you even more, please disregard. Thanks for your hard work, the application is truly impressive!
Shift as a key to trigger an action doesn't feel right to me, I feel like the convention is for shift to be held to enable another trigger (the Tab button) to go backwards.
Even ignoring the Windows comparison, just look at the muscle memory that something like Safari or Finder tabs give you – Ctrl-Shift doesn't do anything in these apps, but if you hold Ctrl and Shift then the "Tab" key will go backwards through the tabs rather than forwards. So I think being consistent with this behaviour would be better.
To have shift-tab cycle backwards instead of shit, you can simply change the default shortcut as such:
This ticket is about discussing having the backward shortcut (whatever it is set to) to invoke AltTab, when AltTab is not yet opened. Today there is no way to do that. This ticket discusses how the implementation would look like here, especially the preferences UI.
I think this feature request is quite niche. Furthermore, the preference UI hasn't been solved. I'll close this ticket for now. Please upvote if you're interested in this feature. Enough upvotes and I'll reopen the ticket 👍
This issue was opened by a bot after a user submitted feedback through the in-app form.
Message: