Compose key input broken in GTK3 applications

Fluora · 2024-08-14 16:54:25

I'm running Plasma under Wayland, and after an update sometime within the last day or two, I noticed that typing certain compose key sequences is no longer possible in GTK3 apps due to strange shift key behavior - namely that pressing the shift key while typing a compose sequence immediately exits the compose input without emitting a character. I can still, for example, type í (compose + i ') as normal, but not ï (compose + i ") since I have to use the shift key to get the " part. I *can* work around this to some extent by holding shift before tapping compose and using sequence variants that have the shifted character first (e.g. compose + " i), which is how I typed this example into firefox just now, but any sequences that need shift to be pressed midway through, like all my custom sequences for the uppercase Greek alphabet, are not possible to access.

Applications in which compose sequences DO work as expected:
- Yakuake
- Dolphin file manager
- Kate
- Audacity
- possibly all Qt apps?
- Dino (gtk4)
- LibreOffice (with SAL_USE_VCLPLUGIN=qt6 or qt5)

Applications in which compose sequences DO NOT work as expected:
- Firefox
- Thunderbird
- LibreOffice (with SAL_USE_VCLPLUGIN=gtk3)

I'm not running a custom input method (e.g. ibus) and am just using Plasma's keyboard layout settings to configure the compose key. My custom sequences live in ~/.XCompose.
I have confirmed that it affects all of my machines that are running Arch and have been updated to the current versions of everything.

Does anyone have any idea what change might have caused this? I can't put it in few enough words to force Google to understand it, so I'm having trouble getting anywhere. It's breaking my workflow fairly badly due to its impact on Firefox.

seth · 2024-08-14 20:16:03

gtk defaults to ibus, compare

gtk3-demo
GTK_IM_MODULE=xim gtk3-demo

Then please post the output of

locale

and try to downgrade libx11, https://bbs.archlinux.org/viewtopic.php?id=298417

Fluora · 2024-08-14 23:13:25

The compose key behavior was broken in gtk3-demo regardless of GTK_IM_MODULE being unset (default on my system), set to xim, or set to ibus. In each case, pressing shift immediately quits compose sequence entry.

locale:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=C
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

You said Gnome defaults to ibus, but my system doesn't have any ibus-related packages installed. Is that as expected?

I'll try downgrading when I have time and report back.

Thanks for the help!

mpan · 2024-08-15 01:26:09

How much I preferred xim and used it myself until recently, I believe it has to be considered obsolete. With many current programs it causes issues and it’s way beyond the misbehavior you described.⁽¹⁾ You don’t have to use IBus in particular: there are other input methods available.

If you want to use it, IBus installation and configuration in Arch is at the wiki. In the past it was pretty primitive and not even handling “~/.XComponse”, but that is no longer the case — if that’s what you are worried about and for what you are staying with xim. Other than keyboard layout switching, which I can no longer can have under LAlt+CapsLock, I managed to configure it to work as if I just had xim.
____
⁽¹⁾ In my case it was leading to GUI flickering in LibreOffice, KiCad display breaking completely at times, and text display issues in some input fields across Gtk-based software.

Last edited by mpan (2024-08-15 01:28:08)

seth · 2024-08-15 08:17:41

In my case it was leading to GUI flickering in LibreOffice, KiCad display breaking completely at times

The bug isn't xim - fcitx5 is likewise affected and the ultimate blame seems to lie w/ gtk (surprise)
https://gitlab.gnome.org/GNOME/gtk/-/issues/2560
There's a full analysis, identification of the breaking commit, pointing out that the causing check seems pointless, "tHe rEcOmMeNdEd fIx iS NoT To uSe xIm"

which I can no longer can have under LAlt+CapsLock

Errr… the xkb group toggle shortcut should™ completely suck away combo and turn it into ISO_Next_Group ?
You're not binding some shortcut to setxkbmap, are you?

mpan · 2024-08-15 12:16:59

seth wrote:

Errr… the xkb group toggle shortcut should™ completely suck away combo and turn it into ISO_Next_Group ?
You're not binding some shortcut to setxkbmap, are you?

You can make a bind, but it will not block the CapsLock key as it would with native Xorg layout switching.

seth · 2024-08-15 13:48:46

You can, but setxkbmap is a really inefficient (and side-effect prone) way to switch layouts.
grp:alt_caps_toggle doesn't allow you to use caps lock otherwise??

mpan · 2024-08-15 17:21:23

I don’t get what you are asking me about now.

You can configure IBus to use LAlt+CapsLock for layout switching, but IBus has no way of preventing the CapsLock press from being registered.

You can configure Xorg to do switching with grp:alt_caps_toggle and that prevents CapsLock presses from being registered, but it also messes up IBus.

seth · 2024-08-15 19:42:50

configure Xorg to do switching with grp:alt_caps_toggle and that prevents CapsLock presses from being registered

That's not supposed to happen at all.

If you set grp:alt_caps_toggle "xev -event keyboard" should™ get you Caps_Lock and Alt+Caps get you ISO_Next_Group
If you cannot get around that otherwise (eg. b/c of ibus interference?) I'd suggest to configure a different combo as toggle and bind a shortcut to "xdotool key ISO_Next_Group"

mpan · 2024-08-16 07:02:53

I still don’t get, what (and why) you’re trying to say. There is some miscommunication, I believe.

seth · 2024-08-16 08:02:30

My guesstimate is that you resorted to some solution where you bound shortcuts to "setxkbmap -layout pl" etc. to switch layouts.
That's not a very good solution (it's excessively slow, clients will frequently miss/ignore the event and any mapping on top, eg. xmodmap, will be lost)

You seem to suggest that you cannot use grp:alt_caps_toggle as "that prevents CapsLock presses from being registered", what is not supposed to be the case.
Maybe it's a bug in ibus, but grp:alt_caps_toggle leaves the caps lock key as Caps_Lock, only the combination with Alt turns into ISO_Next_Group (the "key" that switches the layout)

If it is a bug in ibus and you cannot fix it otherwise, I'd suggest to not use setxkbmap, but configure a proper multi-layout and bind your desired shortcut to "xdotool key ISO_Next_Group" (what will likely require you to configure *one* of the available group toggles, but it doesn't matter which - select a combination you otherwise don't care about)

spacemannn · 2024-08-16 19:53:28

keyd is quite nice. I'm using it successfully on Plasma Wayland. Take a look and see if it fits your purposes. It's quite flexible.
https://github.com/rvaiya/keyd
https://archlinux.org/packages/extra/x86_64/keyd/

mpan · 2024-08-16 21:14:52

seth: so there is miscommunication.

I told OP, that moving to IBus works pretty well, with that single exception. I don’t seek advice or support for that. It would even be unwise to reintroduce Xorg-specific solution, when Wayland is slowly taking over.

The rest seems like a wrong interpretation of what I wrote. But I don’t ask for help, so I don’t see a point in straightening that.

Fluora · 2024-09-29 21:40:22

I finally had some time to sit down and try ibus, and I can't get compose input working at all. Since ibus handles the layout and doesn't seem to have any way to set where the compose key is, I resorted to using a udev hwdb file to set right alt to be a compose key, and this worked, but it still does nothing when ibus is active. Is there some trick to getting compose working in ibus? I tried googling, but found nothing.

I just tried running Firefox with Wayland support disabled, and compose input involving the shift key worked as expected. I think this means xim is not the culprit, and that this is a Wayland-specific issue with GTK3.

seth · 2024-09-30 07:02:45

Does it happen w/ a different wayland compositor (sway, weston, …)?

"GDK_BACKEND=x11" will make gtk clients run on xwayland.
Another thing you could try is to set "GDK_CORE_DEVICE_EVENTS=1"

Also

My custom sequences live in ~/.XCompose.

Please post that and maybe we should take a closer look the "compose key " (Multi_key) which one do you map there how and what if you use another key than (I guess) the caps lock?

Fluora · 2024-10-02 01:49:29

GDK_BACKEND=x11 does work, so I guess that's a workaround for now.
GDK_CORE_DEVICE_EVENTS=1 didn't seem to do anything.
My compose file is indeed old and huge (I started out by copying the default one from /usr/share/X11/locale years ago), so I thought that might be the culprit, but disabling it and using the current system defaults still results in the bug. I can still post it if you think it would be helpful, but it seems like this rules it out.

I will work on trying another wayland compositor.

seth · 2024-10-02 07:56:09

I can still post it if you think it would be helpful, but it seems like this rules it out.

First check the behavior on a different wayland compositor, don't forget to unset the GDK_BACKEND

Arch Linux

#1 2024-08-14 16:54:25

Compose key input broken in GTK3 applications

#2 2024-08-14 20:16:03

Re: Compose key input broken in GTK3 applications

#3 2024-08-14 23:13:25

Re: Compose key input broken in GTK3 applications

#4 2024-08-15 01:26:09

Re: Compose key input broken in GTK3 applications

#5 2024-08-15 08:17:41

Re: Compose key input broken in GTK3 applications

#6 2024-08-15 12:16:59

Re: Compose key input broken in GTK3 applications

#7 2024-08-15 13:48:46

Re: Compose key input broken in GTK3 applications

#8 2024-08-15 17:21:23

Re: Compose key input broken in GTK3 applications

#9 2024-08-15 19:42:50

Re: Compose key input broken in GTK3 applications

#10 2024-08-16 07:02:53

Re: Compose key input broken in GTK3 applications

#11 2024-08-16 08:02:30

Re: Compose key input broken in GTK3 applications

#12 2024-08-16 19:53:28

Re: Compose key input broken in GTK3 applications

#13 2024-08-16 21:14:52

Re: Compose key input broken in GTK3 applications

#14 2024-09-29 21:40:22

Re: Compose key input broken in GTK3 applications

#15 2024-09-30 07:02:45

Re: Compose key input broken in GTK3 applications

#16 2024-10-02 01:49:29

Re: Compose key input broken in GTK3 applications

#17 2024-10-02 07:56:09

Re: Compose key input broken in GTK3 applications

Board footer