Kinto - xkeysnail: alt+left and then cmd+right not work

[medyagh]

after upgrading to latest with Kinto - xkeysnail

in vsocde:

Issue 1

step 1: in the middle of a code, I do alt + (left arrow) a few times and this will jump on each word to the left (works fine) step 2: then I wanna go to the end of the line ( do cmd+right) I expect it to go to the end of the line but instead I see vscode menues are enabled and I am jumping from one menue to another

isssue 2 (simmilar

1- repeat step 1 in previous issue 2- while seeing the character on a word, I wanna move the cursor one left or right but it wont move, I see the vs code top menu is enabled and I am moving from left to right instead of characters in the word

[rbreaves]

This is a difficult one to solve completely, at least without making some changes to vscode.

The Alt menu will sometimes steal focus when it shouldn’t, despite the hackish key remap I employ. (hackish because I throw in some key presses that purposely make the Alt menu lose focus - works most of the time in my testing, and when it doesn't another alt press unfocuses the alt menu.)

A never fail type solution might be to combine it w/ this custom keymap in VS Code as it will make the Alt menu ignore the Alt hotkeys you’re pressing.

You will also want to comment out the M-Left/Right wordwise stuff specific to VS Code under ~/.config/kinto/Kinto.py & then restart the xkeysnail service.

https://github.com/rbreaves/kinto/blob/268a1bdbff4cca6cac51267785267a87d8f4b05a/xkeysnail-config/vscode_keybindings.json

[arnaud-lb]

The Alt menu issue happens in most applications for me: Firefox, Slack, ...

I couldn't find a workaround for Slack, so I remapped LEFT_META to RIGHT_ALT (Alt Gr) instead of LEFT_ALT, which fixed this issue (and broke some shortcuts).

I wasn't able to find who is responsible for the Alt behaviour, though. Is this Gtk ? Is this implemented separately by every app ? Isn't there any way to disable that ?

[rbreaves]

@arnaud-lb I am not entirely sure, which component is most responsible, but I do know input in general is often handled in a variety of ways greater than what macOS or Windows does when it comes to linux.

I had not thought about trying remaps using the right alt vs the left, I may go back and try that in some apps and see how that handles. Firefox is an aberration though as far as I am concerned and apps like Slack or VS Code are built on Electron and yea.. I am not too surprised by its odd behaviors and having little recourse to fixing it more natively. It is interesting to note that Electron apps under Windows does not suffer from a similar problem.. so it would appear that Electron could be built or run in a way to ignore Alt from activating the menu from how it seems, but yes perhaps it is the gtk or a UI wrapper around electron that is the real issue and not electron itself.

[rbreaves]

Also to note here, the xkb implementation of Kinto does not suffer from this problem. Alt based combos pass through without issue - so apparently they fly under the radar somehow and don't get hung up on the Alt menu activation problem.

A potential fix might be to combine a much lighter xkb kinto implementation with the xkeysnail remap. Perhaps implement only wordwise type shortcuts via xkb and strip it out of xkeysnail. Only issue with that is that it means that Kinto might be less Wayland compatible (it isn't currently but xkb certainly isn't).

[rbreaves]

The only real fix for this is to simply manually set your keybinding.json file to the proper remaps. Not much can be done from within the Kinto config file itself.

The installer might could add a fix that could fix the users keybindings file however. I am closing this ticket though. I may try and fix this later still, but as an option during the install or in the tweaks menu (I would also need to offer a fix for sublime text like keybinds at the same time for vscode via an extension and keybinding modifications.)