Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
On Mon, 15 Dec 2025 at 11:18:27 +0800, Mad Horse wrote: I think *if* we can continue to make ibus-gtk4 not have any dependency relationship on libgtk-4-1, then it would be reasonable to make libgtk-4-1 Recommends ibus-gtk4. I think a Depends would be too strong, because it's entirely possible to use GTK with a different input method like FCITX, or no input method at all. You are right, as a certain gnome and fcitx user has complained it at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1122957 . gnome-core is an opinionated metapackage with the components that are considered to be suitable for a "default" GNOME installation. It is possible to use GNOME without having gnome-core installed if you are unhappy with the choices made by GNOME upstream or by Debian's GNOME team, but it is not possible to use GNOME without having libgtk-4-1 installed, so the expected strength of dependencies in each case is different. smcv
Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
> I think *if* we can continue to make ibus-gtk4 not have any dependency > relationship on libgtk-4-1, then it would be reasonable to make > libgtk-4-1 Recommends ibus-gtk4. I think a Depends would be too strong, > because it's entirely possible to use GTK with a different input method > like FCITX, or no input method at all. You are right, as a certain gnome and fcitx user has complained it at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1122957 .
Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
On Thu, 04 Dec 2025 at 15:09:58 -0500, Jeremy Bícha wrote:
Simon, do you have any thoughts on what we should do here?
I have added Depends: ibus to gnome-core today. Maybe I should add
Depends: ibus-gtk4 there too.
I think a Depends or Recommends from gnome-core to ibus-gtk4 (and
perhaps ibus-gtk3 as well) would make a lot of sense.
gnome-shell has Recommends: ibus
ibus has Recommends: gtk4
(More precisely, ibus has Recommends: ibus-gtk4, ibus-gtk3, and their
GTK 2 equivalent ibus-gtk)
libgtk-4-1 doesn't have any dependency relationship on ibus.
Historically, we would have hesitated to have libgtk-4-1 depend on
ibus-gtk4 because of concerns about circular dependencies.
I think *if* we can continue to make ibus-gtk4 not have any dependency
relationship on libgtk-4-1, then it would be reasonable to make
libgtk-4-1 Recommends ibus-gtk4. I think a Depends would be too strong,
because it's entirely possible to use GTK with a different input method
like FCITX, or no input method at all.
GTK 3 and even GTK 2 could get the same treatment (and so could Clutter,
if we weren't trying to remove it already).
*After* each GTK version Recommends the corresponding ibus plugin, we
could also consider relaxing ibus' Recommends on the GTK ibus plugins to
be a Suggests, or removing it completely and relying on GTK to pull in
appropriate plugins to use ibus. I think it would certainly make sense
to drop ibus' Recommends on ibus-gtk down to a Suggests or no
relationship at all, even if the other two stay as Recommends.
So we would have something like this, with all the dependency arrows
in the graph flowing one way, and no cycles:
{-D-> ibus -R/S?--->}
metapackages { } ibus-gtk4
{-D-> GTK4 apps -D-> libgtk-4-1 -R->}
{-D-> ibus -R/S?>}
metapackages {} ibus-gtk3
{-D-> GTK3 apps -D-> libgtk-3-0t64 -R--->}
GTK2 apps -D-> libgtk2.0-0t64 -R->}
} ibus-gtk
ibus -S->}
I'm not
very sure what the problem with circular dependencies is; maybe it's
mostly a problem for bootstrapping?
Partly it's a problem for bootstrapping and minimal build and/or test
environments: the GTK -dev package depends on the shared library, so if
the shared library depends on something that can only be compiled by
using the -dev package, we have a bootstrapping problem. Demoting a
Depends to a Recommends solves this, because buildds don't install
Recommends, and developers don't strictly need to install Recommends
either.
Partly it's an installation problem: if there's a cyclic dependency
between packages that have a postinst, apt cannot implement the Policy
guarantee for Depends. For example if libgtk-4-1 Depends ibus-gtk4 and
ibus-gtk4 Depends libgtk-4-1, Policy says apt must call "dpkg
--configure libgtk-4-1" before "dpkg --configure ibus-gtk4", but Policy
also says apt must do the opposite, and that isn't possible. apt will
resolve this by breaking the cycle in an unpredictable place, which is
out-of-spec behaviour (a Policy violation) that is difficult to reason
about. Demoting a Depends to a Recommends (or less) solves this, by
telling apt: *this* is an acceptable place to break the cycle.
And partly it's a cleanup problem: if a user of a non-GTK-based desktop
like KDE Plasma installs a single GTK 4 app (let's say quadrapassel),
then decides that actually they don't like this app and removes it
again, apt will not automatically clean up the unused libgtk-4-1 and
ibus-gtk4 if they have a circular Depends or even Recommends on each
other: libgtk-4-1 would be kept because ibus-gtk4 depends on it, and
ibus-gtk4 would be kept because libgtk-4-1 depends on it. Demoting a
Depends to a Recommends is not a solution for this, but demoting a
Depends or Recommends to a Suggests solves it.
Related to our multi-year drive to not install gtk2 by default or in
more places than necessary, ibus-gtk4 has a dh_shlibdeps override to
avoid a direct dependency on libgtk-4-1. That may not have been
necessary for gtk4
It's unnecessary *if* we make sure that libgtk-4-1 *doesn't* get a
Recommends or Depends on ibus-gtk4, but what I'm suggesting above is
that libgtk-4-1 Recommends ibus-gtk4 could be a good solution.
I think having this dh_shlibdeps override is a good thing in general: it
was necessary for GTK 2, it will be necessary for GTK 3 when we start
phasing it out in favour of GTK 4 or newer, and it will presumably be
necessary for GTK 4 in a few years' time. It also gives us more options
when it comes to how we avoid cyclic dependencies and cyclic Recommends.
Ideally src:ibus could have an autopkgtest (or even a build-time check)
that inspects the Depends and Recommends of ibus-gtk{,3,4} and asserts
that they don't match /libgtk/? That would have caught the regressions we
Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
On Thu, Sep 18, 2025 at 2:40 AM Frederic Peters wrote: > I went digging and I found the discussion in > https://gitlab.gnome.org/GNOME/gtk/-/issues/7581 > > | On Wayland, this is entirely the responsibility of the compositor: > | we no longer do any compose handling on the client side. > > with a link to > https://gitlab.gnome.org/GNOME/gtk/-/commit/621b7facc8b098811f659a0cba56d27e6ae39ea2 > > and ultimately I read the NEWS file and the note for 4.19.2: > >Note: This release makes GTK rely on the Wayland text protocol >for input method support. For compositors without that protocol, >you can manually set GTK_IM_MODULE=simple to get back support for >X11-style compose sequences and dead keys. > > and that's it, installing ibus fixed that for me. > > ibus is already a Recommends: on gnome-shell, I don't know how GTK > applications would behave on other compositors, and if it would make > sense to add a recommends to gtk4 itself, I'll leave you as the judge > for that. Simon, do you have any thoughts on what we should do here? I have added Depends: ibus to gnome-core today. Maybe I should add Depends: ibus-gtk4 there too. gnome-shell has Recommends: ibus ibus has Recommends: gtk4 libgtk-4-1 doesn't have any dependency relationship on ibus. Historically, we would have hesitated to have libgtk-4-1 depend on ibus-gtk4 because of concerns about circular dependencies. (I'm not very sure what the problem with circular dependencies is; maybe it's mostly a problem for bootstrapping?). The workaround has been to use Recommends instead of Depends. Related to our multi-year drive to not install gtk2 by default or in more places than necessary, ibus-gtk4 has a dh_shlibdeps override to avoid a direct dependency on libgtk-4-1. That may not have been necessary for gtk4 and maybe we're far enough along that ibus' gtk2 support could be removed now. Thank you, Jeremy Bícha
Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
Jeremy Bícha wrote: On Wed, Sep 17, 2025 at 5:19 PM Frederic Peters wrote: After upgrading from 4.18.6 to 4.20.1 compose and dead keys (e.g. ^ then e on a. French layout keyboard) stopped working; typing compose ' e inputs 'e instead. of é, typing ^e inputs "e" instead of "ê". Switching back to a X11 session restored the expected behaviour. I am unable to reproduce this issue with the information you have provided, using Debian Testing today. I created a new user and it also happens for it, also I forgot to note this but keys are working fine in other programs (GTK3, Firefox, Kitty). I went digging and I found the discussion in https://gitlab.gnome.org/GNOME/gtk/-/issues/7581 | On Wayland, this is entirely the responsibility of the compositor: | we no longer do any compose handling on the client side. with a link to https://gitlab.gnome.org/GNOME/gtk/-/commit/621b7facc8b098811f659a0cba56d27e6ae39ea2 and ultimately I read the NEWS file and the note for 4.19.2: Note: This release makes GTK rely on the Wayland text protocol for input method support. For compositors without that protocol, you can manually set GTK_IM_MODULE=simple to get back support for X11-style compose sequences and dead keys. and that's it, installing ibus fixed that for me. ibus is already a Recommends: on gnome-shell, I don't know how GTK applications would behave on other compositors, and if it would make sense to add a recommends to gtk4 itself, I'll leave you as the judge for that. Thanks, Fred
Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
On Wed, Sep 17, 2025 at 5:19 PM Frederic Peters wrote: > After upgrading from 4.18.6 to 4.20.1 compose and dead keys (e.g. ^ then e on > a. > French layout keyboard) stopped working; typing compose ' e inputs 'e instead. > of é, typing ^e inputs "e" instead of "ê". > > Switching back to a X11 session restored the expected behaviour. I am unable to reproduce this issue with the information you have provided, using Debian Testing today. I was able to use my Compose key (which I enabled and set to Right Alt) in my en_US layout. I disabled the Compose key and then I switched my layout to Belgian. I was then able to get an ê by typing Right Alt+^ , e . (The ^ character is the key to the right of the p key, represented as an [ on my en_US keyboard.) Thank you, Jeremy Bícha
Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland
Package: libgtk-4-1 Version: 4.20.1+ds-2 Severity: normal Hi, After upgrading from 4.18.6 to 4.20.1 compose and dead keys (e.g. ^ then e on a. French layout keyboard) stopped working; typing compose ' e inputs 'e instead. of é, typing ^e inputs "e" instead of "ê". Switching back to a X11 session restored the expected behaviour. Have a nice day, -- System Information: Debian Release: forky/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.16.7+deb14-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgtk-4-1 depends on: ii adwaita-icon-theme 49.0-1 ii hicolor-icon-theme 0.18-2 ii libc6 2.41-12 ii libcairo-gobject2 1.18.4-1+b1 ii libcairo-script-interpreter21.18.4-1+b1 ii libcairo2 1.18.4-1+b1 ii libcloudproviders0 0.3.6-3 ii libcolord2 1.4.8-1 ii libcups2t64 2.4.10-4 ii libepoxy0 1.5.10-2 ii libfontconfig1 2.15.0-2.4 ii libfribidi0 1.0.16-1 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-5 ii libgles21.7.0-1+b2 ii libglib2.0-0t64 2.84.4-3 ii libgraphene-1.0-0 1.10.8-5 ii libgstreamer-gl1.0-01.26.6-1 ii libgstreamer-plugins-base1.0-0 1.26.6-1 ii libgstreamer1.0-0 1.26.6-1 ii libgtk-4-common 4.20.1+ds-2 ii libharfbuzz-subset0 11.4.5-1 ii libharfbuzz0b 11.4.5-1 ii libjpeg62-turbo 1:2.1.5-4 ii libpango-1.0-0 1.56.3-2 ii libpangocairo-1.0-0 1.56.3-2 ii libpangoft2-1.0-0 1.56.3-2 ii libpng16-16t64 1.6.50-1 ii librsvg2-2 2.60.0+dfsg-1+b1 ii libtiff64.7.0-5 ii libvulkan1 1.4.321.0-1 ii libwayland-client0 1.24.0-2+b1 ii libwayland-egl1 1.24.0-2+b1 ii libx11-62:1.8.12-1 ii libxcursor1 1:1.2.3-1 ii libxdamage1 1:1.1.6-1+b2 ii libxext62:1.3.4-1+b3 ii libxfixes3 1:6.0.0-2+b4 ii libxi6 2:1.8.2-1 ii libxinerama12:1.1.4-3+b4 ii libxkbcommon0 1.7.0-2.1 ii libxrandr2 2:1.5.4-1+b3 ii shared-mime-info2.4-5+b3 Versions of packages libgtk-4-1 recommends: ii iso-codes4.18.0-1 ii libgtk-4-bin 4.20.1+ds-2 ii librsvg2-common 2.60.0+dfsg-1+b1 Versions of packages libgtk-4-1 suggests: ii gvfs 1.58.0-1 Versions of packages libgtk-4-1 is related to: pn fcitx5-frontend-gtk4 pn ibus-gtk4 pn scim-gtk-immodule -- no debconf information
