Application launcher cannot be started with European keyboards

[Hofer-Julian]

Distribution:
PopOS 20.04 beta

Issue/Bug Description:
In the German keyboard layout, the "/" is only indirectly accessible by pressing Shift+7.
However, the application launcher (with it's default shortcut Super+/) is not accessible via Super+Shift+7 nor with any other combinations I've tried.

Note:
I guess other keyboard configuration as well as other shortcuts are affected as well.

[mmstick]

What key do you use for searches in vim / less / etc. ?

[Hofer-Julian]

Shift+7 (for less, I barely use vim)

[alexjp]

@Hofer-Julian the launcher should appear with "Super+7" ( without the shift, I have Portuguese keyboard, and its the same placement of "/" )

EDIT: weird, I am sure that it was working previously with "Super+7" ( hence i found this issue, while trying to find out how to change it ), but upon a reboot its not working anymore!

[Hofer-Julian]

I had a similar experience.

In Live-Mode, Super+7 worked. After I've actually installed PopOS it did not.

[WatchMkr]

We also have two reports (pop-os/beta#76 + one internal) that "/" on a numpad does not work.

[phil-opp]

Is there a way to change this shortcut? I don't see it anywhere under "keyboard shortcuts" in settings.

[leviport]

It is in Keyboard Shortcuts under the "Navigate applications and windows" section.

[phil-opp]

I don't have this option in that section:

[ThaSiouL]

German keyboard here, Super + F7 and the numpad "/" aren't working for me either. The shortcut is not listed for rebind either.

Does anyone know how else too call the launcher so we can manually readd a keyboard shortcut as a workaround?

[xdursoc]

I don't have in the keyboard shortcuts the possibility to change the default shortcut super + /

[mmstick]

What would be a good key for everyone?

[xdursoc]

I think that super + alt could be good, the second problem is that there is not the possibility to edit the shortcuts, almost for me, on ubuntu 20.04.

[ThaSiouL]

on my standard German layout super + # would be about the same physical location as super + / on an US keyboard and is currently not in use.

As long as it becomes rebindable I'm happy!

[WatchMkr]

German keyboard here, Super + F7 and the numpad "/" aren't working for me either. The shortcut is not listed for rebind either.

I had a similar experience.

In Live-Mode, Super+7 worked. After I've actually installed PopOS it did not.

@mmstick I think this is the root of the issue. Let's figure out what's going on with this. And the second problem appears to be that the shortcut isn't showing up in Keyboard Shortcuts for some people (so that it may be easily modified).

[nicolae-stroncea]

Super + Any number will affect a lot of users: by default it launches applications from the dock, and many users also configure it to change to different workspaces as i3 does it.

[jtorrensamer]

on my standard German layout super + # would be about the same physical location as super + / on an US keyboard and is currently not in use.

As long as it becomes rebindable I'm happy!

In Spanish "#" is by pressing Altgr + 4, so, is not good solution super + # (will be Super + Altgr + 4).

[jtorrensamer]

May be Super + space? Is not in use.

[Hofer-Julian]

Super+space is in use, it's for switching keyboards.

I actually, think that @mmstick original question was spot on. What is the expected behavior from other applications?

The answer being, Super + wherever / is on your keyboard.

In the case of the German keyboard, that would be Super + Shift + 7

[WuerfelDev]

Super + Any number will affect a lot of users: by default it launches applications from the dock, and many users also configure it to change to different workspaces as i3 does it.
Exactly, we have two keybindings on that combination right now

Super + Shift + 7 is IMO very unpleasant for something essential as the menu. Wouldn't like this.
I would maybe use Super + D as keybinding because we're used to it from dmenu in i3, but it is already used to show the desktop. What do you think about Super + X?

[Slate245]

I've also just stumbled upon this issue after installing Pop for the first time.

I'm using two keyboard layouts (US and RU) so, in one the shortcut works fine, but on the other it does nothing.

Is there a way to assign multiple keybindings to the same action? I've tried searching through dconf editor, but it lists only default gnome keybindings.

[ids1024]

I don't have this option in that section

Hm, it seems to be missing there for me as well, even though it's defined to appear there by /usr/share/gnome-control-center/keybindings/10-pop-shell-navigate.xml.

Looking into this.

[ids1024]

Is there a way to assign multiple keybindings to the same action? I've tried searching through dconf editor, but it lists only default gnome keybindings.

Pop!_Shell does seem to support this, and in fact uses it, supporting both arrow keys and vi-style h/j/k/l. Gnome Control Center doesn't seem to handle this (#435).

@Slate245 It's rather awkward, but this sets it two two keys: dconf write /org/gnome/shell/extensions/pop-shell/search "['<Super>slash', '<Super>x']"

[ids1024]

After testing a few things, I think this setting not appearing may be due to a bug in gnome-control-center.

In 10-pop-shell-navigate.xml, there is a line line this:

<KeyListEntry name="search" description="Launch and switch applications"/>

But in 01-launchers.xml, there's this:

<KeyListEntry name="search" description="Search" msgctxt="keybinding">Search</KeyListEntry>

These should be entirely independent. They are in different schemas, but happen to have the same key name. But removing this line from 01-launchers.xml makes the "Launch and switch applications" setting show up, as it is supposed to.

[ids1024]

The settings issue is being tracked at pop-os/gnome-control-center#93.

But for this issue, I guess we're just in need of a choice of default key binding that works well across keyboard layouts?

Super + Shift + 7 is IMO very unpleasant for something essential as the menu. Wouldn't like this.
I would maybe use Super + D as keybinding because we're used to it from dmenu in i3, but it is already used to show the desktop. What do you think about Super + X?

Another possibility is Super+R, which opens the run dialogue in Windows. I seem to vaguely recall that might be the default in some tiling window manager I used once as well...

Doesn't look like that conflicts with anything?

[WatchMkr]

Let's keep the default Super+/ key binding. We need to fix the bug that Super+7 doesn't work consistently on international keyboards (shift should not be required) and of course fix the bug that the key binding doesn't show up in Keyboard Shortcuts.

[ids1024]

Let's keep the default Super+/ key binding. We need to fix the bug that Super+7 doesn't work consistently on international keyboards (shift should not be required)

Okay. Switching to a German keyboard layout, Super+7 seems to work for me. So I guess it's a matter of tracking down why it's doing that some times and not others...

[ids1024]

I've found how to reproduce this. When booting with the en keyboard layout, and switching to de or pt, Super+7 works. But if I boot with the de layout, it doesn't. This would explain the report that it worked in the installer, but not after rebooting.

We're using the Gnome Shell method Main.wm.addKeybinding to set the binding, so it's probably an issue in some upstream component. But whatever the cause and whatever upstream considers correct behavior, it's surely unintentional that it works one way when switching from en but a different way on a cold boot with that layout...

We also have two reports (pop-os/beta#76 + one internal) that "/" on a numpad does not work.

@WatchMkr This seems intentional, at least as far as Gnome Shell is concerned. It considers this a separate binding, <Super>KP_Divide rather than <Super>slash.

If we want to support that, we can add that as a second binding, since Pop shell supports multiple bindings (though it can't be configured properly: #435). But I'm not sure that would be useful.

[ids1024]

I've found how to reproduce this. When booting with the en keyboard layout, and switching to de or pt, Super+7 works. But if I boot with the de layout, it doesn't. This would explain the report that it worked in the installer, but not after rebooting.

I've reproduced this in a clean Fedora Workstation 32 VM. But it doesn't seem to quite be the layout used at boot... the behavior is a bit stranger. I guess it's a bug in Mutter, or maybe GTK? I'll see if I can figure out exactly what situation reproduces this, and send a bug report upstream.

[ids1024]

With further investigation, I seem to have narrowed it down. This prevents the issue:

• Open "Settings"
• Go to "Region & Language"
• Select "Manage Installed Languages"
• Change "Keyboard input method system" from "IBus" to "none"
• Reboot

After this, no matter what I do, Super+7 seems to start the launcher on the "de" layout. Which I guess is what we want.

So it seems IBus (or possibly the GTK/Mutter integration for IBus) breaks this. There seems to be some inconsistency in the behavior with IBus (not sure exactly what's going on there), but without it, the behavior is consistent.

Edit: Okay, that also seems to not consistently fix it...

[ids1024]

I've submitted an issue to Mutter; hopefully they have some idea about the cause: https://gitlab.gnome.org/GNOME/mutter/-/issues/1311

[ids1024]

After skimming the keybinding code in Mutter, creating a VM to test a version of mutter built from git, and running various tests with Mutter's logging enabled... it seems the underlying issue has nothing to do with keyboard layouts.

Mutter logs this, under the English layout:

KEYBINDNGS: Grabbing keybinding keycode 61 mask 0x40 on 0x3b5

Keycode 61 is the location of / character on the English keymap. Mask 0x40 seems to be the super key. So this is what we expect, and it works.

Then under the German layout:

KEYBINDNGS: Grabbing keybinding keycode 16 mask 0x40 on 0x3b5

16 is where / is on this layout, so this is what we expect. So it should work... but doesn't. And then... wait, it prints lines like this even when a key isn't bound!

New steps to reproduce

• Boot from a Pop!_OS live USB, an installed Pop!_OS system, or anything else running Gnome
• Bind a key to super+7. It doesn't work.

Explanation

Try typing super+1, and onwards down the number keys. It seems Gnome binds super+1 to the first "favorite" app, super+2 to the next, etc. So super+7 if bound already to something else (but does nothing, unless you use "add to favorites" a few times to have a seventh one to launch.)

I'm not sure exactly what component of Gnome is responsible for this (Probably gnome-shell).

The actual bug

Mutter seems to silently add another keybinding with the say keycode and mask with no feedback to the user. The nondeterminism reported here seems to be due to some varation in the order the keybindings end up being added, or something along those lines.

Gnome Control Panel should be aware that these key bindings are in use.

The super+1... behavior should probably be customizable in the keyboard settings.

This issue

I'm not sure how we want to resolve this. I can think of a couple ways:

• Find where Gnome is adding these bindings, and patch it to disable that. But it is potentially useful functionality, so I don't know we want to remove it.
• Change super+/ to another combination that works on all layouts without conflicting with anything is still an option.

@WatchMkr Thoughts on these two solutions, or any others?

[ids1024]

In particular, this binding conflicts with switch-to-application-7 defined in org.gnome.shell.gschema.xml. Gnome Control Center is not configured to be able to change those bindings.

[ids1024]

Or a third solution would be that this should be triggered by super+shift+7, which is probably what I would expect, and shouldn't conflict with anything. I don't know if that's the behavior that would be expected by people more used to switching keyboard layouts than me.

This would affect other key bindings, would likely require fundamental changes to how key bindings are implemented in Mutter, and is presumably something we would only want to do if upstream agrees. (And if we want the default binding to be ergonomic on different layouts, this wouldn't solve that.)

[ids1024]

pop-os/session#20 is merged, and released to the 20.04 repositories, so super+7 should work reliably now. That may not be a convenient binding, but it can also be changed now.