Applications seeing a mix of symbols through the extend layer, and of the original keypress, triggering unwanted keybindings
antoine-gallix opened this issue · 3 comments
Hello, first of all I want to thank you for your fantastic work on the extend layer. I had something similar programmed in the keybindings of my main applications since many years and was trying to implement something similar with xkb to have it system-wide. I've spend countless hours fighting with xkb without success; finding your work was such a relief. That's splendid in term of ergonomic. I couldn't find another way to contact you so I'm thanking you here.
Now for the problem at hand. The extend layer is working correctly in the few application I've tried up to the moment I opened VS-Code. Note that I am using the extend on top of my usual keyboard, for now a eurokey layout that is a classic us layout with an improved 3rd level.
First, with the word movements. To move a word left or right I first maintain pressed capslock(level5) + F(ctrl). VScode first opens the search widget, because it somehow detected a ctrl+f press. So somehow the press contol of the extend layout went through, but at the same time also the f letter. A first workaround was for me to unbind the ctrl+f keybinding. Then to the next quirk.
Now trying to make a trail-select-word, usually given by shift+ctrl+arrow, I find again the same type of problem. Pressing capslock+f+d should give me the equivalent of ctrl+shift, but somehow the keybinding assigned to ctrl+shift+d get triggered. If I keep those three pressed, and then press J or L to move the cursor and select words, if works fine. But in the process that hybrid shift+ctrl+d was detected and a side window opened. Somehow again the software received the shift+ctrl from the keyboard map, but at the same time detected on it's own that the letter key have been pressed.
As debugging information, using xev in a terminal shows me no trace of receiving the D letter when pressing and maintaining, in order, capslock and D.
I imagine it's maybe not directly related to your layout, but indirectly. The question is, is it possible for applications to read directly the key presses and do their own interpretation of them, and at the same time accessing the output of xkb? How is it possible that this application get the ctrl from your layout when I press capslock+f, and at the same time detect a f, which is like the raw key press? And conclude to trigger the ctrl-f keybinding? Or could it be that the capslock key would be considered as release, thus also sending the f key afterward? But in this case after removing the keybinding, and pressing capslock+f, I don't see any f printing?
All of this is pretty mysterious. Any idea what kind of mechanism is at work here?
This seems to be a problem inside VS-code who recently decided to read keycodes instead of keysyms. microsoft/vscode#23991
Yes, some programs will read key codes directly and that may cause problems for users of alt-layouts.
On a side note, I think the EURkey layout isn't so good. I've discussed that at length elsewhere, but basically it falls into the same pit as Shai's own AltGr layers: Trying to do everything at once causes a confusing and unsatisfactory result. You have intuitive mappings for a few accents, but others are relegated to unintuitive key mappings which frankly, sucks.
These days I'm doing a lot of work on the Compose key, but that's using EPKL on Windows. There is of course a nice Compose key in the X server, since Compose is an old Linux favorite and what taught me about it. But the flexibility to edit its function by layout and enhance it further is something I've done with EPKL alone so far. With individual Compose mappings, you can solve the problem of mapping overload very elegantly.
Yes I think I got seduced by the "united europe" tone of the EurKey layout. But after a while, I pretty much agree with your conclusions.