Revisit scriptable / shortcut invocation of switcher window (without dismissing) for binding to a mouse click / trackpad gesture.

[frypf]

Is your feature suggestion related to a problem? Please describe.
Following on from #458 and touched upon briefly in #566, it would be very useful to be able to bring up the switcher without it being dismissed upon release of the modifier key. #458 already implements this via the "then release" behaviour, although this then applies to both shortcuts 1 and 2, ie. sacrificing the existing keyboard functionality in order to have the mouse binding.

Ideally I'd love to be able to keep the standard modifier-release behaviour with the keyboard but also have the option of calling the switcher with the mouse and having it hang around onscreen until I click to select an app (or click outside to cancel). I use BetterTouchTool for binding shortcuts / scripts to gestures... other options are available.

Describe the solution you'd like
A few thoughts on this front as I'm aware of @lwouis's ongoing battle with bloat in the preferences UI while still wanting to give users maximum options for tailoring the app to their own workflow. I'd personally be happy with any of these (they're not in order of preference), although it's entirely at his discretion as to how feasible any of them may be. And obviously this is just for my own use-case, others please comment if they have any insight!

• Separate the "then release" behaviour for shortcuts 1 and 2:
  This was mooted in Alternate control scheme: can release the shortcut without the UI going away #458 although would seemingly require quite a bit of code refactoring. Personally I don't currently use shortcut 2, although for those who do this may still represent something of a sacrifice for one bit of functionality over another. I'm definitely not advocating any option for "shortcut 3" 😅.

• A script trigger eg. Applescript to show the window without dismissing it:
  Clicking "Show" in the menubar currently does exactly this, although it'd be great to be able to bind this specific function directly to a trackpad gesture without having to go via a keyboard shortcut. This would also avoid any changes in the prefs UI, and allow shortcuts 1 and 2 to retain their current functionality / usefulness. This could be a toggle, either showing or hiding, but this is definitely not integral as we can already simply click outside of the switcher to dismiss it. I have no idea how difficult or long-winded this would be to implement.

• Allow selection of what is shown when AltTab is reopened whilst already running:
  Currently if I reopen AltTab whilst it's running (via Spotlight or double-clicking the app), the prefs window is brought up. Perhaps a dropdown in the prefs could allow users to select between prefs, shortcut 1 switcher or shortcut 2 switcher. I can foresee issues with this for those who hide the menu bar icon, as they could then be left without a means to bring up the preferences.

(For either of the latter 2 options, it'd be the icing on the cake if it didn't automatically highlight the 2nd app in the list, but by no means a dealbreaker).

Describe alternatives you've considered
I had a look at (dirty, dirty) GUI scripting a click on "Show" in the menu bar, but couldn't get anywhere with it:

tell application "System Events" to click menu item 1 of menu bar 2 of process "AltTab"

correctly activates the menu, but it seems impossible for Applescript to interact with the items within the menu. Accessibility Inspector shows the following:

Maybe it's a limitation of menu extras, maybe it's as simple as adding an accessibility description. Maybe I'm just missing something obvious.

[lwouis]

Your solution 2 and 3 are very creative, I like that! 👍

I think I'll go for number 1. Hopefully I don't re-discover the reason I scoped this out of #458. Hopefully it was not motivated by a tricky technical blocker.

[frypf]

Hopefully I don't re-discover the reason I scoped this out of #458. Hopefully it was not motivated by a tricky technical blocker.

I was conscious that might've been the case so I just thought I'd come up with some alternative options. My programming knowledge is limited and I've spent the last few days reading through a number of your reasoned arguments for and against certain features, wanting to keep the UI clean and self-explanatory and also trying to offset effort against gain. Having said that, I'm pretty sure implementing a whole Applescript Dictionary for a single function that no-one else is asking for would be non-trivial 😂

[lwouis]

I implemented this ticket. Could you please try it out and let me know if it works for you?

[frypf]

Yep seems fine! Thanks again 👍