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
