Dear Maintainer,

From 1:49+8, gnome-core starts to DEPEND on ibus, which makes ibus being
forcefully installed when existing users upgrade their gnome-core, and breaks
existing gnome user configs using other input method frameworks such as fcitx.
If users want to keep using their favorite input method frameworks other than
ibus, they might have to uninstall gnome-core, gnome, and task-gnome-desktop
along with ibus, and might lose other packages which gnome-core depends in the
process.

It might be better to make gnome-core "Recommend" ibus, as how gnome-shell
does, rather than "Depend" on it.

Just as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1115532#30 noted, gnome-core DEPENDING on ibus might be too strong.

Could you provide a detailed test case of how exactly ibus being
installed causes breakage?

We added the Depends because ibus not being installed broke some
keyboard input on GNOME on Wayland, at least for a fr_BE.UTF-8 locale
as described in the original bug https://bugs.debian.org/1115532 .

Thank you,
Jeremy Bícha

Before upgrading to 1:49+8, I used to use fcitx5 (only present input framework, being the default one) along with gnome, but after upgrading to gnome-core 1:49+8, a bare core ibus was installed without any actual input engine, and further more, ibus was chosen as the default input framework under gnome, making me lose access to any installed input engines. (if launching another desktop environment, the default input framework remains fcitx5) I should either start to use ibus instead and install actual input engines for ibus, or manually set fcitx5 as my input framework with im-config.

If you need a test case, you can install task-gnome-desktop, remove gnome-core, ibus, and install fcitx5, then install gnome-core and observe the change of launched input framework.

Please be more precise. Starting from a new install of Debian 13 with
GNOME, how do I configure Debian to use fcitx5? What exact input
method and locale configuration do I need and how do I set that up?

Thank you,
Jeremy Bícha

Install of Debian 13 with GNOME, set locale to zh_CN.UTF-8, remove gnome-core, ibus, and install fcitx5, fcitx5-frontend-all, fcitx5-chinese-addons, and reboot. At this point one should have fcitx5 as default input framework with fcitx5-pinyin input engine under gnome.

Hi,

During pre-bookworm release of im-config, I was told that fcitx5 now offers
compatible API as ibus.  So where ever ibus is used, fcitx5 (not fcitx4) can be
used as drop in replacement.  When both are available, ibus seems to be used
over fcitx5.

So changing dependency to "ibus" only to "ibus|fcitx5" may be simple immediate
solution for gnome-core.

That's my thought on this bug report.

There can be other associated changes:  for example, fcitx5 to be "provides:
ibus" while conflictiing/replacing with "ibus" .   (I haven't thought through
complication for this in depth.  Maybe I got this idea
from https://www.phoronix.com/news/MTM0NjU )

Also, when input method support at wayland level becomes available, that is
going to use ibus API.  So fcitx5 can be used as well.  But I think it hasn't
been done yet,  ... or done already.  I don't have link to this assertion.

Here are a few links around this compilicated and fluid topic.
* As I see: https://github.com/ibus/ibus/issues/2331, [1] ibus was not using
wayland-level in 2021
* https://en.opensuse.org/SDB:Wayland_input_methods this is 2025.  KDE in SUSE
seems to select fcitx5 and ibus.
* https://wayland.app/protocols/xx-input-method-v2 seems to indicate wayland
seems to have unified input method API (2nd version)
* https://dorotac.eu/posts/input_method/ this is wayland input article

Anyway, once wayland-only system is introduced, im-config should becomes
inactive under such configuration.  im-config should servefor  good old X11
sytems.

So future should be:
* Linux VT console only: uim and emacs
* X11: im-config supported IMs: ibus, fcitx5, (uim if there is enough patch
coming to me)
* Wayland: im-config is NOP under this config.  So I need to figure out reliable
detection.

 

[1] https://github.com/ibus/ibus/issues/2331,
https://github.com/ibus/ibus/issues/2331

Hi,

During pre-bookworm release of im-config, I was told that fcitx5 now offers
compatible API as ibus.  So where ever ibus is used, fcitx5 (not fcitx4) can be
used as drop in replacement.  When both are available, ibus seems to be used
over fcitx5.

So changing dependency to "ibus" only to "ibus|fcitx5" may be simple immediate
solution for gnome-core.

That's my thought on this bug report.

There can be other associated changes:  for example, fcitx5 to be "provides:
ibus" while conflictiing/replacing with "ibus" .   (I haven't thought through
complication for this in depth.  Maybe I got this idea
from https://www.phoronix.com/news/MTM0NjU )

Also, when input method support at wayland level becomes available, that is
going to use ibus API.  So fcitx5 can be used as well.  But I think it hasn't
been done yet,  ... or done already.  I don't have link to this assertion.

Here are a few links around this compilicated and fluid topic.
* As I see: https://github.com/ibus/ibus/issues/2331, [1] ibus was not using
wayland-level in 2021
* https://en.opensuse.org/SDB:Wayland_input_methods this is 2025.  KDE in SUSE
seems to select fcitx5 and ibus.
* https://wayland.app/protocols/xx-input-method-v2 seems to indicate wayland
seems to have unified input method API (2nd version)
* https://dorotac.eu/posts/input_method/ this is wayland input article

Anyway, once wayland-only system is introduced, im-config should becomes
inactive under such configuration.  im-config should servefor  good old X11
sytems.

So future should be:
* Linux VT console only: uim and emacs
* X11: im-config supported IMs: ibus, fcitx5, (uim if there is enough patch
coming to me)
* Wayland: im-config is NOP under this config.  So I need to figure out reliable
detection.

 

[1] https://github.com/ibus/ibus/issues/2331,
https://github.com/ibus/ibus/issues/2331