Alphabetical sort requires multiple keypresses to quick toggle between two windows - please add option for AltTab to open with next window selected

[eshoyfer]

When alphabetical sort is on and AltTab is triggered with Opt+Tab*, it opens with your current window is selected. To select the next one, another tap of Tab* is required. If the shortcut combination is released without another tap of Tab*, the selection pop-up disappears with its focus having remained on the _current window- and nothing happens. This means that to flick between two open windows, you need to do the following (relatively cumbersome) sequence: Opt+Tab*, Tab*, release, [work in app], Opt+Tab*, Tab*. release, [original window]. This is different from how Windows works: Alt+Tab, release, [work in app], Alt+Tab, release, [original window]. It opens with the next window already selected for you, making fast toggle quite intuitive.

AltTab already works with way when you have window order set to "Recently Focused." This is because the cursor stays in place while the windows switch position each time, allowing you to just release the key combination to toggle. When sort is changed to alphabetical, this behavior is disrupted. The feature that is being requested is for the best of both words — an alphabetical sort that embraces quick toggle between the two most recently focused windows. This allows for the muscle memory/dock-like pre-arrangement advantages of alphabetical sort to coexist with the utility of a fast toggle of recently focused sort.

*or with your shortcut combination of choice, as configured

[lwouis]

@XOR-op introduced the sorting feature:

For order other than "Last Focused", I will make the initial focused window the same as the last focused window. When we use order other than "Last Focused", our window may (most probably!) not the first window in the order. Initially focus the second window don't make sense. And since users may not navigate right, move the focused window right by 1 is not a good choice. So I decide to make it the same as the last focused window, leaving the user to choose where to navigate.

@XOR-op what do you think of @eshoyfer's feedback?

[XOR-op]

Hi @eshoyfer, glad to hear your feedback. My implementation is based on a observation: when you use alphabetical sort, your current window is (mostly) not your first window, e.g. the 5th window out of 9. In alphabetical order, no assumption should be put to which window you will choose next. You may go backward or forward with equal probability. Thus, one window forward in alphabetical order should not be a good choice, since it assumes you want go forward with more probability. I don't use Windows often, but IIRC Windows only supports most-recently order, whose behavior I don't change.

I don't fully understand your desired behavior, so here are my understandings:

1. If you want to switch between two alphabetically adjacent window with only one click (I read from para 1), it looks like a niche need to me. Since users cannot control app's name, I'm afraid such a behavior could not satisfy most users' need.
2. If you want to have an alphabetical view as well as a most-recently musule memory, I'd suggest you use two key combinations, which is what I'm doing. I use one key combo for predictable layout and another for traditional alt-tab.
3. If you want to use most-recently switching inside an alphabetical view, it would be an interesting idea although I think there are many limitations about it. We can discuss if you do mean this.

[eshoyfer]

Thanks for the detailed response!

I've begun to use what you've described in #2 as a workaround. What I originally had in mind was #1, but based on your description of the reasoning behind the current functionality, I've come to understand that what I'm interested in is likely scenario is #3.

Yes, the hybrid of an ordered view (such as alphabetical or spaces) with a most-recently used switching selection mechanism seems like something that could be appealing, especially as an alternative to using two separate schemes as in #2.

[XOR-op]

I think the biggest problem is that it may be less efficient as imagined. In an ordered view, you don't have any expectation of what the next-recently-used window is. Since there is no explicit view of the recently-used order, you need to search and react to it every time you press tab*, which is like a Whac-A-Mole game. Personally I won't use this pattern if I am looking for the window with distance>2.

Second, it would be unintitutive to users. I don't know how we can add a long description to the mechanism, neither name it properly if we add an option for it. I believe some users would struggle with this if we don't add any hints.

Personally, I don't want to implement this myself because of my time and a requirement of older version XCode to contribute to the project (#2581). But I suggest you try to implement it if you're interested, and use it personally to find if it works as intended or not.

P.S. It'd be better not use sharp+number here, since it'll be parsed as a reference to issues automatically by github.