Keyboard shortcuts not working with different keyboard layouts

Hi folks,

I’m a member of the Serbian translation team and for a couple of GNOME releases, I’ve noticed that keyboard shortcuts do not work as they used to do.

Couple of examples, typing in the password to login after sleep in the lock screen, you make a typo, you press Ctrl+A and Backspace to delete the whole password. This works if your keyboard layout is set to en_US but not if it’s sr_RS.

It’s not only the gdm, it’s the same in the apps. If I want to open a new terminal tab in Ptyxis, I press Ctrl+Shift+T. This works if the layout is en_US but not for sr_RS.

I need to fill a bug report but I’m not sure against which component. Can somebody tell me which component is the most likely culprit here?

Thanks in advance! :slight_smile:

1 Like

Is that layout using the Cyrillic A? I would assume that apps/toolkits only define keybindings for the Latin A.

Yes, it’s a Cyrillic A. But the thing is, this used to work before, a couple of releases ago.

There is some code in mutter for global keybindings to also try to resolve them using a latin layout, but I don’t think there is anything similar for widget-specific keybindings, such as on the lock screen. Was it specifically Ctrl+A (which is widget-specific) that was working or was it something like Super+A (which is global)?

I went and installed Fedora 34 in a VM and even there you can’t Ctrl+A with the sr_RS layout to select all the text. I was mistaken but I might open a PR to see if this could be improved.

On the application side, on Fedora 41, I can get Ctrl+Shift+T to work as expected with sr_RS in gnome-terminal but other terminal emulators like Ptyxis and Console do not. Pressing Ctrl+T in Nautilus also works correctly with sr_RS layout.

Since it works in the old Gnome Terminal, this must be an issue with ptyxis and console, right?

Could also be in gtk4, since gnome-terminal still uses gtk3, while the other two use gtk4.

2 Likes

The relevant code for global keybindings would be src/core/keybindings.c. Search for active_layouts to get an idea how this is implemented.

The code for the password widget (and all other text entries) uses ClutterBindingPool, with the lookup happening in clutter_binding_pool_activate().

1 Like

Hi, just as another data point, ctrl-shift-T also doesn’t work with my BÉPO keyboard on ptyxis, fwiw.
Cheers,

Interesting. So, the information in the GtkShortcutsWindow though translated to a particular language, might not always work with the keyboard layout associated with that language ?

The shortcuts in GtkShortcutsWindow are defined separately from the code that actually handles the shortcuts. So theoretically it could happen that the shortcuts shown there don’t work at all if they are not kept in sync with the code. That also means that translating those won’t affect the actual behavior unless the actual shortcuts can also be translated and have a matching translation. No idea if either of these are supposed to be translated though.

But I was talking more in general, not specifically about gtk. Maybe gtk does have some code to also look up shortcuts using a fallback Latin layout similar to what gnome-shell/mutter does for global shortcuts, but it’s not working for some reason. However Clutter as used in gnome-shell widgets doesn’t have such code.

What I meant was when shortcuts in code / .ui and GtkShortcutsWindow are in sync, and GtkShortcutsWindow is translated to a non-latin language (say, X), it gives the impression that the shortcuts are supported for the keyboard layout for language X, when in fact the key combinations displayed in the GtkShortcutsWindow might not even exist on the keyboard layout for X.

But I was talking more in general, not specifically about gtk. Maybe gtk does have some code to also look up shortcuts using a fallback Latin layout similar to what gnome-shell/mutter does for global shortcuts, but it’s not working for some reason. However Clutter as used in gnome-shell widgets doesn’t have such code.

Thanks for the info. I didn’t know that.