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

Per-shortcut "select previous window" shortcut #1159

Open
alt-tab-macos-bot opened this issue Sep 27, 2021 · 13 comments
Open

Per-shortcut "select previous window" shortcut #1159

alt-tab-macos-bot opened this issue Sep 27, 2021 · 13 comments
Labels
enhancement New feature or request niche Nice idea, but not enough demand for it

Comments

@alt-tab-macos-bot
Copy link

This issue was opened by a bot after a user submitted feedback through the in-app form.

From: [email protected]

Message:

Changing "Select previous window" to ⇧⇥ changes that for both shortcuts at once. This is rather annoying as ⇧⇥ makes perfect sense for the ⌥⇥ shortcut, but it doesn't make sense for the ⌥ shortcut (that one should be ⇧). This isn't a problem with the defaults as the default for "Select previous window" is just ⇧, but it's a problem once that's changed.

@lwouis
Copy link
Owner

lwouis commented Sep 28, 2021

I'm sorry i read your message 2 times but can't understand the issue you're facing. Could you try to explain again? Maybe screenshots would help illustrate how you set your preferences as well.

@lilyball
Copy link

lilyball commented Oct 1, 2021

The preference for "Select previous window" is global rather than per-shortcut. This is okay for the default Shift hotkey, but this does not work well when I set it to Shift+Tab (to match the behavior of Cmd+Tab; just tapping Shift to go backwards is confusing). This does not work well because it means the shortcut to go backwards is still Shift+Tab even when using Shortcut 2, which does not otherwise involve the Tab key. For Shortcut 2 I want that to be Shift+` instead (to match Alt+`), but I can't change that without it changing for Shortcut 1 as well.

Screenshots

Shortcut 1Shortcut 1
Shortcut 2Shortcut 2

@lwouis
Copy link
Owner

lwouis commented Oct 2, 2021

I understand better now.

I can't see a clear nice solution to accommodate your desired use-case though. Most people want the "while open" shortcuts to be global. If we make them per-shortcut, people will have to remember to set them in both sections every-time. We will have more than 2 shortcuts in the future as well so it seems like it would be a poor UX.

I'm afraid i can only suggest to use a global one like shift or shift+tab

@lwouis lwouis closed this as completed Oct 2, 2021
@lwouis lwouis added the enhancement New feature or request label Oct 2, 2021
@lwouis lwouis changed the title [In-app feedback] Per-shortcut secondary shortcuts Oct 2, 2021
@gautamjain
Copy link

Hi @lwouis. So happy to have finally discovered alt-tab! It's perfect.

I'd like to have the "select previous window" key be separate for Shortcut 1 and Shortcut 2 too. Basically, I'd like to be able to do this:

Next window
Cmd + Tab
Cmd + `

Previous window
Cmd + Shift + Tab
Cmd + Shift + `

I agree that if all of the "while open shortcuts" are made shortcut-specific, the UX would become very complicated. But changing only the "previous window" shortcut from global to shortcut-specific seems like it wouldn't be too confusing IMO.

@lwouis
Copy link
Owner

lwouis commented Oct 7, 2021

@gautamjain if we bring the Select previous window in the section above, per-shortcut, then it would mean it can be used to summon AltTab when AltTab is not visible. There are issues with this. Please see #510

@lilyball
Copy link

@lwouis It could be listed as a "While open" shortcut in the section above. That said, given existing platform behavior with ⇧⌘⇥ and ⇧⌘`, it certainly makes sense for ⇧⌥⇥ to also be a trigger. But that's orthogonal to making it a per-shortcut customization and should not be considered a blocker.

Also, in the very last comment of #510, you yourself suggested setting "Select previous window" to ⇧⇥, which causes the issue described in this ticket.

Can we please get this ticket reopened? Regardless of how it's resolved, this is definitely an issue.

@lwouis lwouis reopened this Oct 21, 2021
@lwouis lwouis changed the title Per-shortcut secondary shortcuts Per-shortcut "select previous window shortcut Oct 21, 2021
@lwouis lwouis changed the title Per-shortcut "select previous window shortcut Per-shortcut "select previous window" shortcut Oct 21, 2021
@lwouis
Copy link
Owner

lwouis commented Oct 21, 2021

@lilyball I re-opened this ticket. I also renamed it as it is seems the discussion is only about the "Select previous window" shortcut, not other secondary shortcuts

@sonofjon
Copy link

sonofjon commented Jul 7, 2022

As AltTab is advertised as "AltTab brings the power of Windows alt-tab to macOS" it would make sense if the "select previous window" functionality works as on Windows, which is what this issue is asking for.

@lwouis lwouis added the niche Nice idea, but not enough demand for it label Nov 6, 2022
@mrnoname1000
Copy link

mrnoname1000 commented Mar 20, 2024

I use ⌥⇥ to switch between all windows and ⌘` to switch between app windows, but I'm unable to add a shift to these shortcuts to mirror the native ⌘⇥ behavior. I'd like to use ⌥⇧⇥ to select the previous global window and ⌘⇧` for the previous active app window.

@michkozak
Copy link

I was about to create a new issue about this very topic, but thankfully it's already open 😄.

I'll try to explain my reasoning behind +1'ing this one the best I can.

Since #3819 has been successfully resolved few days ago, I've been able to finally take AltTab for a proper spin — and this behavior was one of the very first things I've noticed and bothered me. I gave it a fair few days, hoping that maybe I would get used to that, but it's not happening.

Why the current behavior is not ideal

It's simply too big of a dissonance between how AltTab works and how the built-in app switcher works in macOS. Dissonance introduces friction, and friction leads to irritation.

The built-in app switcher has a very elegant and predictable navigation paradigm: you press ⌘⇥ to move forward between applications and and ⌘` to move forward between current application's windows, and if you want to move backward you keep the shortcuts the same, but add a ⇧ modifier, so going backward between applications becomes ⌘⇧⇥ and going backward between current application's windows becomes ⌘⇧`. It's very logical.

AltTab, being an alternative or a companion switcher, utilizes ⌥ instead of ⌘, so it doesn't collide with the built-in switcher in any way.

It makes perfect sense to try to mimic the system behavior to minimize mental overhead when trying to summon AltTab, so you set a shortcut for going forward between applications to ⌥⇥ and a shortcut for going forward between current application's windows to ⌥`. And now, naturally, you'd want to set a shortcut for going backward between applications to ⌥⇧⇥ and a shortcut for going backward between current application's windows to ⌥⇧`.

Unfortunately, currently you cannot set different shortcuts for Shortcuts When ActiveSelect Previous Window for Shortcut 1 through 5. Once you set it for one of them, it sets it for all of them.

UI/UX challenges

On the UI/UX front: I'm not sure that it would require any major changes or introduce any confusion. We're all familiar with the concept of tabs and the concept of current tab, being exposed to them in various ways over years of browsing the internet and using native apps.

Currently, when you're in AltTab's settings in the Controls section, the sub-tabs for Shortcut 1 through 5 are clearly visually highlighted — there's no confusion as to which Shortcut number you are changing settings for.

Furthermore, when you switch between Shortcut 1-5, only the highlight changes, but everything below it doesn't. If that's not confusing and you know you're now changing settings for a different Shortcut number — why would it be for Shortcuts when active... ?

If I'm in the settings for Shortcut 1, it seems logical that clicking on Shortcuts when active... will bring up a modal for setting shortcuts for that Shortcut 1, same as it's clear I'm changing, say, the Show hidden windows setting for that Shortcut 1 if it's currently highlighted.

So, UI-wise, this would not require any changes.

If anything is not clear, I'd be happy to record a video showing and explaining it.

@mx1up
Copy link

mx1up commented Nov 15, 2024

I was in the exact same situation when I started using AltTab. It is so logical to add the shift modifier to go backwards on the current key combo, so indeed ⌥⇧⇥ for going back through all windows and ⌥⇧` to go back between application windows. I thought I'd never be able to adjust to AltTab's current behavior.

However, after a few weeks of usage, I did not notice the discrepancy anymore and my brain was adjusted. I think the main reason for quite easy adjustment was, that pressing ⌥⇧` is too difficult, I have to reach too far. So it turned out to be okay :)

So in the end, I'm happy it is working the way it is :) However, for some people, especially when using other shortcuts, I could see it still being a problem. It doesn't hurt to make the behavior configurable..

I'd like to take the opportunity to thank the author of this tool. Without it, macOS would simply be unusable for me.

@michkozak
Copy link

michkozak commented Nov 16, 2024

I was in the exact same situation when I started using AltTab. It is so logical to add the shift modifier to go backwards on the current key combo, so indeed ⌥⇧⇥ for going back through all windows and ⌥⇧` to go back between application windows. I thought I'd never be able to adjust to AltTab's current behavior.

However, after a few weeks of usage, I did not notice the discrepancy anymore and my brain was adjusted. I think the main reason for quite easy adjustment was, that pressing ⌥⇧` is too difficult, I have to reach too far. So it turned out to be okay :)

So in the end, I'm happy it is working the way it is :) However, for some people, especially when using other shortcuts, I could see it still being a problem. It doesn't hurt to make the behavior configurable..

I'd like to take the opportunity to thank the author of this tool. Without it, macOS would simply be unusable for me.

Quick questions: are you using AltTab exclusively, instead of the built-in app switcher ? Or alongside the built-in app switcher? I could see some people being able to get used to that behavior if they're only using AltTab. Can't imagine how anyone could get used to that discrepancy if they're using both (and there is a reason to do that, I'm one of those people).

It's a surprisingly high mental overhead for such a small thing, but it's real and taxing.

I suppose it's because the two things are very similar in purpose, function and even looks. It would be probably much easier to get used to that for a whole different app, that does a different thing.

But in case of AltTab and built-in app switcher: they're very similar, you use them for practically the same thing — with only small differences. So your brain puts them in the same bag. And if you have two tools that both perform the same function, the only difference being in how they go about it and that difference being small — you naturally expect them to behave the same and the shortcuts to be "portable" between them, with only a small difference (here that small difference should only be the "main" key that summons them: ⌘ for built-in app switcher, ⌥ for AltTab).

I stand by my previous comment about the UI/UX too: there's really no change needed (I explained why in the comment above). The only change would be under the hood.

@tacomanator
Copy link

agreeing with @michkozak and suggest matching built-in ⌘⇥ behavior for ⇧ modifier.

The built-in macOS app switcher uses ⇧ only to reverse direction. AltTab should ideally match this behavior, or at least offer it as a configurable option defaulting to the native behavior. This would:

  1. Reduce cognitive load when switching between AltTab and native switcher
  2. Maintain consistency with established macOS UX patterns

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request niche Nice idea, but not enough demand for it
Projects
None yet
Development

No branches or pull requests

9 participants