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

[QUESTION] Why block M-Tab with pass_through_key? #508

Closed
RedBearAK opened this issue May 10, 2021 · 2 comments
Closed

[QUESTION] Why block M-Tab with pass_through_key? #508

RedBearAK opened this issue May 10, 2021 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@RedBearAK
Copy link
Contributor

@rbreaves

You said this previously about the way pass_through_key works in your fork of xkeysnail:

Also the pass_through_key is not what it sounds like - it actually intentionally cancels out that particular key so that it literally does not pass_through - it blocks it from going through. I cancel out the newly mapped location of the alt key while remapping the Cmd key location to be Alt-Tab at the same time. This also only works because of my custom fork of xkeysnail. Otherwise the tab switcher would typically appear and quickly disappear because held keys is not a real concept in xkeysnail by default.

I'm using Ubuntu 21.04 and felt like enabling both "Switch applications" (my preferred task switching, like macOS) and "Switch windows" shortcuts at the same time, but Kinto was blocking setting "Switch windows" to physical Win+Tab (logical Alt+Tab) because of the pass_through_key line:

    K("M-Tab"): pass_through_key,                 # Default - Cmd Tab - App Switching Default

So I commented that out and mapped M+Tab to C+Tab instead:

    # K("M-Tab"): pass_through_key,                 # Default - Cmd Tab - App Switching Default
    K("M-Tab"): K("C-Tab"),                       # Default - Cmd Tab - App Switching Default
    K("RC-Tab"): K("M-Tab"),                      # Default - Cmd Tab - App Switching Default
    K("RC-Shift-Tab"): K("M-Shift-Tab"),          # Default - Cmd Tab - App Switching Default
    K("RC-Grave"): K("M-Grave"),                  # Default not-xfce4 - Cmd ` - Same App Switching
    K("RC-Shift-Grave"): K("M-Shift-Grave"),      # Default not-xfce4 - Cmd ` - Same App Switching

Now I have:

  • "Switch applications" on the physical location equivalent of Cmd+Tab
    (using physical Alt+Tab, logical RC+Tab, mapped back to Alt+Tab), and
  • "Switch windows" on the physical location equivalent of Option+Tab
    (using physical Win+Tab, logical Alt+Tab, mapped to Ctrl+Tab).

Each shortcut is working and brings up a different style of task switcher dialog.

I haven't had any issues in this GNOME-based DE with disabling the pass_through_key line that blocks M+Tab. Tried it in KDE Neon, disabling the line doesn't seem to cause any problem there either. With or without mapping Alt+Tab to Ctrl+Tab as an alternative.

You mentioned in the quote above that the tab switcher could appear and then suddenly disappear, but I haven't experienced anything like that after disabling the line.

Is there a specific DE (or keyboard type?) where that line solves a problem that I'm not seeing in GNOME or Plasma with a PC keyboard?

@RedBearAK RedBearAK added the question Further information is requested label May 10, 2021
@rbreaves
Copy link
Owner

rbreaves commented May 11, 2021

Cmd-Tab changes the app that has focus and Ctrl-Tab changes tabs within an app. Macs don't really have anything mapped to their alt/opt-tab so it goes away, that is why I cancel it out. If I don't cancel it out then it'd be like having 2 Cmd-Tab hotkeys on different modifiers. The physical Cmd-Tab location should continue to work - as will the virtual M-Tab press it maps to - if that is not the case then I am not aware of that issue.

@RedBearAK
Copy link
Contributor Author

Ah, got it. All very logical.

Ctrl-Tab changes tabs within an app

That... I was not too familiar with. Never really used it before. (Been using the Ctrl+PgUp/PgDn keys for that.) Now I see how you dealt with that, specifically remapping Super+Tab (Ctrl key) back to LC-Tab:

    K("Super-Tab"): K("LC-Tab"),                  # Default not-chromebook
    K("Super-Shift-Tab"): K("LC-Shift-Tab"),      # Default not-chromebook

If I don't cancel it out then it'd be like having 2 Cmd-Tab hotkeys on different modifiers.

Yes, I did think part of the reason might just be to avoid confusing users with two key combos acting the same, if it's not mapped to something else. Good reason, too.

I sometimes forget to think about things from the perspective of how things are originally set up on macOS. You're much better at that.

The physical Cmd-Tab location should continue to work - as will the virtual M-Tab press it maps to - if that is not the case then I am not aware of that issue.

Nope, no issue. Had no trouble with Cmd+Tab location, just wanted to see if I could have "Switch applications" on that and "Switch windows" on the key right next to it, for quick comparisons between the different switchers, and noticed that I couldn't set it to the Win+Tab combo (nothing would register), but I could do something like Win+Backslash or RC-Backslash without issue. It all makes much more sense now.

Thanks! This was very helpful.

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

No branches or pull requests

2 participants