Fixing the alt+shift switching issue in Linux for applications on Electron

Hello, colleagues!

I want to share my solution to the problem mentioned in the title. I was inspired to write this article by a colleague brnovk, who took the time to propose a partial (for me) solution to the problem. I created my own 'workaround' that helped me. I'm sharing it with you.

Problem Description

I used Ubuntu 18.04 for work and recently noticed that when switching layouts using alt+shift in applications like Visual Studio Code, Skype, Slack, and others built with Electron, the following issue occurs: focus moves from the input field to the window's top panel (menu). For various reasons, I moved to Fedora + KDE and realized that the problem persisted. In search of a solution, I found a wonderful article Fixing Skype on Your Own. A huge thanks to my friend brnovk, who explained the problem in detail and shared their method of solving it. However, the method described in the article only addressed one application, namely Skype. It was also critical for me to figure out how to handle Visual Studio Code, because writing messages with a jumping menu, while annoying, isn't as troublesome when you're developing. Additionally, the colleague proposed a solution that completely hides the application's menu, which I would prefer not to lose in VS Code.

I tried to understand what the issue was

So, I decided to take some time to investigate the issue. I will now briefly describe the path I took; perhaps someone more knowledgeable in this matter can help clarify the difficulties I encountered.

I opened Visual Studio Code and started pressing different combinations of Alt+, watching the application's reaction. In almost all cases, all combinations, except for Alt+Shift, worked without losing focus. It seemed that someone was consuming the pressed Shift, which followed after holding Alt, and the application thought that I pressed Alt, then didn't press anything, released Alt, and it happily threw my focus to its menu, which seemed quite logical to it.

I opened the keyboard layout switching settings (you know, that long list with checkboxes and various settings for keys) and set the layout switching to the Alt key, without any additional presses.

After this, Alt+Tab stopped working for window switching. Only Tab worked, which means someone was once again 'eating' my Alt key. There were no questions left about who this 'someone' was, but I had no idea what could be done about it.

However, since the problem needed to be solved somehow, a solution came to mind:

1. In the settings, disable the hotkey for switching keyboard layouts (uncheck all boxes in the 'Switch to another layout' section);
2. Create my own hotkey that would switch the layout for me.

Solution Description

First, we will install a program that allows assigning commands to keys, Xbindkeys. Unfortunately, the standard tools did not allow me to create a hotkey for combinations like Alt+Shift through a nice interface. You can create something for Alt+S, Alt+1, Alt+Shift+Y, etc., but that doesn't suit our task.

sudo dnf install xbindkeysrc

You can find more details about it on ArchWiki
Next, we will create a sample configuration file for the program. The sample is quite short, with several commands — just what is needed to understand how to work with it:

xbindkeys -d > ~/.xbindkeysrc

As seen from the example in the file, we need to specify the hotkey we want to use and the command that should be executed. It looks simple.

# Examples of commands:
"xbindkeys_show"
  control+shift + q
# set directly keycode (here control + f with my keyboard)
"xterm"
  c:41 + m:0x4

As a hotkey, you can use human-readable notation or key codes. I only got it to work with codes, but there's nothing stopping you from experimenting a bit.

To get the codes, you need to use the command:

xbindkeys -k

A small 'X' window will open. You should only press keys when this window is focused! Only in this case will you see something like this in the terminal:

[podkmax@localhost ~]$ xbindkeys -k
Press combination of keys or/and click under the window.
You can use one of the two lines after "NoCommand"
in $HOME/.xbindkeysrc to bind a key.
"(Scheme function)"
    m:0x4 + c:39
    Control + s

In my case, the combination for Alt+Shift looks like this:

m:0x8 + c:50

Now, it is necessary to ensure that pressing this combination results in a layout switch. I found only one working command for specifying the layout:

setxkbmap ru
setxkbmap us

As seen from the example, it can only turn on one layout or the other, which is why nothing but writing a script came to mind.

vim ~/layout.sh
#!/bin/bash
LAYOUT=$(setxkbmap -print | awk -F + '/xkb_symbols/ {print $2}')
if [ "$LAYOUT" == "ru" ]
        then `/usr/bin/setxkbmap us`
        else `/usr/bin/setxkbmap ru`
fi

Now, if the .xbindkeysrc and layout.sh files are in the same directory, the final appearance of the .xbindkeysrc file looks like this:

# Examples of commands:

"xbindkeys_show"
  control+shift + q

# set directly keycode (here control + f with my keyboard)
"xterm"
  c:41 + m:0x4

# specify a mouse button
"xterm"
  control + b:2
#А вот то, что добавил я
"./layout.sh"
  m:0x8 + c:50

After that, we apply the changes:

xbindkeys -p

And you can check it. Don't forget to disable any layout switch options in the default settings.

Summary

Colleagues, I hope this article can quickly help someone get rid of a pesky problem. Personally, I spent my entire weekend trying to figure out and solve the issue so that I wouldn't be distracted by it during working hours. I wrote this article to save someone time and stress. Many of you use an alternative method for switching layouts and don't understand what the problem is. Personally, I like to switch using Alt+Shift, and I want it to work just like that. If you share my opinion and have encountered this issue, this article should help you.

Source: habr.com