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

Key remap as an option? #3

Open
LPFchan opened this issue Jun 27, 2024 · 1 comment
Open

Key remap as an option? #3

LPFchan opened this issue Jun 27, 2024 · 1 comment

Comments

@LPFchan
Copy link

LPFchan commented Jun 27, 2024

Hi, I've remapped Left Ctrl key at the place where Left Command would be on a Mac, hence it would be perfect if this program supported Ctrl+Tab instead of Alt+Tab as an option. Pretty please! 🙏

@stianhoiland
Copy link
Owner

stianhoiland commented Jun 29, 2024

I've done this as well, as I sometimes use an Apple keyboard on Windows.

The layout of the left modifier keys on a Apple keyboard is:

[control] [option] [command]

The layout of the left modifier keys on a Windows keyboard is:

[ctrl] [win] [alt]

First, to match the location of the [alt] key with the [option] key (these two keys perform pretty much the same actions on macOS vs. Windows), you want to remap the left [win] key to the left [alt] key. So now the left modifier key layout looks like this:

[ctrl] [alt] [win]

And now for the protip:

Lots of Windows and macOS keyboard shortcuts are the same except for substituting the [ctrl] key and the [command] key. So, to get macOS-like modifier key layout on a Windows keyboard, while simultaneously retaining the original overlap of the left [ctrl] key and the left [control] key (since there is significant overlap of keyboard shortcuts here, like next/previous tab), instead of remapping the left [win] key and the left [ctrl] key, you want to remap the left [win] key and the right [ctrl] key, so that the left modifier key layout looks like this:

[left ctrl] [left alt] [right ctrl]

Now, just about the only basic keyboard shortcut where substituting the [ctrl] key and the [command] key does not result in the same functionality, is exactly [alt]+[tab] / [cmd]+[tab].

Therefore I have a AutoHotkey script running when I'm using the Apple keyboard, which intercepts right [ctrl]+[tab] and instead sends [alt]+[tab].

With these 2 key remappings (left [alt] <-> left [win] & left [win] <-> right [ctrl]) and that single hotkey override (plus a custom hotkey, right [ctrl]+[space] to press the left [win] button), the basic keyboard shortcuts are covered.


But if you are already using a custom window switcher like cmdtab, it makes sense to skip the AutoHotkey script[1] and just be able to invoke the custom window switcher with, ex. right [ctrl]+[tab], which is what you are asking for.

Atm, cmdtab doesn't support runtime configuration. At some point I'll probably get to it. But one of the reasons why I don't support it yet, is that it is much easier to configure this in the source code and recompile than you might think. If you have a compiler installed (msvc [recommended], clang, gcc, etc.) or are willing to get ahold of one, let me know if you want some simple instructions on how to achieve the customization you want by changing a single value in the source code and recompiling. Again, it's simpler than you might think.

[1] I'm putting a footnote here regarding AutoHotkey because eventually I found myself wanting not just basic keyboard shortcuts to be the same between Windows and macOS, but application specific hotkeys too, such as navigating files in File Explorer with hotkeys like in Finder, etc. And, whereas this is way beyond the scope of cmdtab, for this, AutoHotkey is the right tool. So maybe not dismiss the utility of AutoHotkey for this use case.

As a closing note, I do have a desire to make a tool based on the Interception library to automatically perform these key re-mappings and custom application hotkeys, but on a "driver level" (the tool itself would not be driver level, see the docs for Interception) for higher reliability, and especially for distinguishing Apple-layout keyboards from Windows-layout keyboards, so that you can have both Apple-layout keyboards and Windows-layout keyboards connected and only override the modifier layout on inputs from the Apple-layout keyboard and not the Windows-layout keyboard.

Some day...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants