feat: add Vim-style window selection shortcuts

[david-r-cox]

This change introduces a new "Vim keys" option for window selection controls. With this option turned on, it is possible to select windows in AltTab without leaving the home row of the keyboard.

The keys H, J, K, and L move the window selection left, down, up, and right, respectively. AltTab already uses H as the default key to hide and show apps. If "Vim keys" is turned on when the H, J, K, or L keys are in use by one or more shortcuts, the conflicting shortcut(s) will be overridden until Vim keys is turned off.

For more information on Vim, see https://www.vim.org/about.php

[david-r-cox]

Here are a few screenshots that illustrate the visible aspects of the change:

New "Vim keys" button

Alert shown upon enabling Vim keys when h, j, k, or l are already assigned

Alert shown upon restoring shortcuts overridden by Vim keys

Alert shown when trying to assign h, j, k, or l while Vim keys is enabled

[lwouis]

Looking at the screenshots, i'm thinking that when you open the preferences a month after you have activated vim keys, nothing indicates that the Hide/Show app is actually not active.

I'm thinking that it may be clearer and more consistent to have this UX:

• User clicks vim keys checkbox
• If any vim key is already assigned, user gets a warning with 2 options:
  • Unassign existing keys and activate vim keys
  • Cancel (don't activate vim keys)

If the user confirms, it unassigns all conflicting shortcuts.

I think this UX is better. It's similar to what we do when the user sets an action using an already taken shortcut. We offer a choice to go through and unbind the previous one, or to cancel. I've also seen this UX in many popular apps

[BrendanAnnable]

This is the my most missed feature from my previous alt tab program (HyperSwitch).

Is this PR still alive? Anything I can do to help? 🙂

[lwouis]

@david-r-cox will you pursue this PR?

[david-r-cox]

@lwouis thanks for the ping. Other than the UX, I think this PR is functionally complete. I can rebase so that we can merge today if you'd like, otherwise I'll schedule some time to work on the UX in the next few weeks.

If anyone (perhaps @BrendanAnnable?) is interested in tackling the UX component I'd be glad to give them a quick rundown of how the feature is implemented.

[david-r-cox]

@lwouis I've resolved the merge conflicts and done some live-on testing. I think it's pretty solid and can be merged. I'm happy to look at any remaining UX issues as a follow-up PR.

[lwouis]

Hi @david-r-cox I've tested this branch today after rebasing it. It behaves like you explained previously here.

I would like that the PR integrates the feedback I gave previously. I think the current UX is not robust enough to ship. I would like for this to use the same UX as the other shortcuts already use:

I'm happy to look at any remaining UX issues as a follow-up PR.

The way this project work is that when we merge on master, it triggers CI/CD, and a new version of the app is published all automatically. Thus I only merge on master when things are fully finished and tested. Furthermore this PR is quite modest in its scope and size, so I suggest you simply iterate on it and improve the UX, and once it's ready to go I can merge it as one solid feature and it will release a new version of the app to all users.

[david-r-cox]

Hey @lwouis and fans of AltTab and Vim 👋

I wanted to let you know that I haven't forgotten about this PR!

I'll try make some time for the final changes before the end of the year so that we can all start 2023 with super-efficient window navigation.

I've been busier than ever working on Integrated Reasoning. If anyone would like to jump in and get this across the finish line earlier, I'd be glad to walk them through the current changes and remaining work.

[goldlil]

@david-r-cox maybe this is too much hardcoded approach, it would be better if we add beside arrows option to custom bind. Most guys use hjkl but some use jkl; and jikl, I'm on colemak layout and I use neio for eg. Maybe best approach would be to allow user to define their custom navigation keys. If you have time to walk me through, I would be glad to jump in few weeks when I'll have more time.

[lwouis]

@goldlil this would require some sort of sub-menu / popover. Most users don't need this, so we would tuck away these custom keys in a sub-section of the UI. I think you should first clarify how the UI would look like before digging into code.

[david-r-cox]

Sad news fans of AltTab and Vim :(

I was hoping to knock this out over the holidays as my 2023 is booked up. I ended up busier than anticipated over the break, so its unlikely that I'll be able to make further contributions to this PR until 2024 at the earliest.

If anyone would like to jump in and get this across the finish line earlier, I'd be glad to walk them through the current changes and remaining work.

[elton2048]

Hi @david-r-cox I've tested this branch today after rebasing it. It behaves like you explained previously here.

I would like that the PR integrates the feedback I gave previously. I think the current UX is not robust enough to ship. I would like for this to use the same UX as the other shortcuts already use:

I'm happy to look at any remaining UX issues as a follow-up PR.

The way this project work is that when we merge on master, it triggers CI/CD, and a new version of the app is published all automatically. Thus I only merge on master when things are fully finished and tested. Furthermore this PR is quite modest in its scope and size, so I suggest you simply iterate on it and improve the UX, and once it's ready to go I can merge it as one solid feature and it will release a new version of the app to all users.

Hi there! This MR is closed and the feature is not in the master branch now. As the original author is busy with his own project, it seems difficult for him to continue the work and apply what you have mentioned in this comment.

I tried the original commit by rebasing the latest branch and it is still working! Thanks @david-r-cox work. So I think the next step is how to cooperate with the comment you have mentioned. I tried to apply the flow, but found out that the current logic which checks shortcut is already used is coupled in the UI component (CustomRecorderControl.swift), which makes the existing checkbox UI not possible to apply. It might require some kind of refactoring, like extract the checking function out, and apply such function in both UI callback and internal wiring logic to add shortcut (I think something like addShortcut function in ControlsTab file). Any better idea is definitely welcome!

@lwouis what do you think? I can try to do that if the approach is good enough in production.

[lwouis]

Hi @elton2048 ,

Yes, that sounds good 👍

Thank you

[skolj]

Hi @lwouis, I just created #2865 which tries to implement the UX discussed here.