Add option to switch windows when shortcut key is pressed

[casey]

Thanks for making this project!

I like alt-tab a lot, but I'm used to cmd-, so I'd like to be able to configure the behavior of alt-tab to be as close to cmd- as possible.

In particular, I'd like an option to be able to make alt-tab focus the next window in sequence immediately when pressing the shortcut key, instead of waiting for the shortcut modifier to be released.

[lwouis]

I'm not sure i understand your request. It seems you want a UX with no interface. You would press cmd-tab, and it would focus the previous window instantly, then every press of tab pour focus the previous ones. The UI and window thumbnails would never appear.

Am i understanding correctly?

[casey]

If the apparition delay was high, you could press the shortcut several times to cycle through multiple windows without seeing the UI. If the apparition delay was low or zero, the UI would appear as normal, but windows would be focused (although behind the alt-tab switcher dialog) as you pressed the shortcut key.

[lwouis]

Ok i see, that makes sense. It's uncommon to want that workflow, but i can see its merits

[casey]

Do you think it would be a big change? I'm a developer, although only a little highly outdated Mac development experience, so if you could give me some code pointers, I might be able to take a crack at it.

[lwouis]

First you should define the feature a bit more. For instance, how does the preferences look like with it?

This is what we have today:

I could suggest we replace the whole Then release: + dropdown with a single dropdown.

So instead of:

Then release: * Focus selected window
              * Do nothing

We would have:

* Then release: Focus selected window
* Then release: Do nothing
* And focus selected window

It makes the preferences less understandable, which is never good (see #351), but maybe it's worth it? To be honest, I wish a few more people would ask for this feature before adding it, with the added complexity, bugs, maintenance, supporting users about it, etc, that it would introduce.

Regarding giving you pointers, first I suggest you read the Contributing docs. They give an overview of how the project is setup, and how to build/run.

Beyond that, I think having focus on select should be pretty easy to implement. There is already a method to focus a window, you just want to call it on the event which move the selected thumbnail. There are many edge-cases of course: going forward, going backward, key is kept pressed so repeats which quickly cycles, currently selected window is closed in the background so we need to select another, new window is spawned, etc. But if you add the .focus() call in the right place, all these cases should be included 👍

[casey]

First you should define the feature a bit more. For instance, how does the preferences look like with it?

I was thinking that there would be a checkbox that said "Focus window on key press" that would be unchecked. There could also be a dropdown that said "Focus window on key {press,release}". The checkbox or the dropdown could be in the Miscellaneous section.

It makes the preferences less understandable, which is never good (see #351), but maybe it's worth it?

I feel your pain! I'm just one user, who knows if anyone else wants this feature, and if it makes the preferences worse, then maybe it's not worth it. I maintain a project that gets all kinds of wacky feature requests, so I'm always facing the same dilemma.

I think a "Miscellaneous" section checkbox that can be ignored probably doesn't make the preferences much worse. Making the main drop down weirder is not great. So I personally would lean towards doing the former. And instead of doing either, we could always leave this issue open and let it marinate for a while and see if anyone else wants it.

Regarding giving you pointers, first I suggest you read the Contributing docs. They give an overview of how the project is setup, and how to build/run.

Beyond that, I think having focus on select should be pretty easy to implement. There is already a method to focus a window, you just want to call it on the event which move the selected thumbnail. There are many edge-cases of course: going forward, going backward, key is kept pressed so repeats which quickly cycles, currently selected window is closed in the background so we need to select another, new window is spawned, etc. But if you add the .focus() call in the right place, all these cases should be included 👍

Nice, thank you for the pointers!

[lwouis]

Yes, it's a tricky balance to offer preferences to all sorts of users. Your suggestion of a "Miscellaneous" is similar to some apps hiding such options into an "Advanced" or "Expert" section.

The downsides of bagging everything in a dark corner is that it can quickly start to look like a dusty closet where stuff is simply dumped.

The Then release: Do nothing preferences was added after a few users requested to keep AltTab open on release. Though it is an uncommon workflow, I could imagine it would help people, for example to bind mouse buttons to shortcuts to use AltTab mouse-only. That's why there is a dropdown there today. The advantage of putting that preference in the main preferences UI is that people can discover it and it can inspire them to use uncommon workflows. That being said, of course it also has downsides like making the main UI messy here.

Since we already have the dropdown for different behaviors on release, I think we may as well just extend it this time.

Also, if we add a checkbox, I feel the UI would be misleading as it the checkbox would say "Focus window on key press", but the existing dropdown would still say "Then release: Focus selected window" which would mean we focus again on release. Which I think we wouldn't want there. Which is why I suggested the 3 options in a dropdown, with the dropdown now including the Then: section.

In any case, if you share a PR, I'll merge it, because I always value people contributing code more than anything else. I also like the idea of letting it open to see if more people are interested. Maybe other people could help with the UI side as well.

[casey]

I tried building the project using the suggested command:

xcodebuild -workspace alt-tab-macos.xcworkspace -scheme Debug

But got the following errors:

/Users/rodarmor/src/alt-tab-macos/Pods/Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.7, but the range of supported deployment target versions is 10.9 to 12.2. (in target 'Sparkle' from project 'Pods')
/Users/rodarmor/src/alt-tab-macos/Pods/Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.6, but the range of supported deployment target versions is 10.9 to 12.2. (in target 'LetsMove' from project 'Pods')
** BUILD FAILED **


The following build commands failed:
  CompileSwift normal arm64 /Users/rodarmor/src/alt-tab-macos/src/logic/Preferences.swift (in target 'alt-tab-macos' from project 'alt-tab-macos')
  CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'alt-tab-macos' from project 'alt-tab-macos')
(2 failures)

[lwouis]

Check out this video: https://discord.com/channels/642999627255382042/642999627259576320/939658396628566108

[casey]

I just checked out that video and it doesn't show how to deal with the error I got.

[lwouis]

@casey at around 1:40, they change the deployment target, which is the error you're getting. I imagine it would fix the error for you as well. I can't help more because my computer is still on Catalina with an older XCode, which matches the Travis VM for CI/CD as well. So these errors happening on newer macOS/XCode, I can't help with, beyond sharing what other people have done about them, such as this video on Discord. It looks like if you repeat those steps you would be able to build though.

[lwouis]

HyperSwitch has a bit of a similar feature where if you hover a thumbnail, it will bring a clone of the window, dimmed, to the foreground. This helps localize the window.

I think we can't straight up focus the windows. This would actually make the thumbnails jump around in the carousel because their focus order would change. That's probably why HS shows these fake dimmed windows preview thingies, instead of bringing the actual windows to the front.

In addition, I think this feature request is quite niche, so I'll close this ticket for now. Please upvote if you're interested in this feature. Enough upvotes and I'll reopen the ticket 👍