Support input methods on wayland and actually via wayland

[leolost2605]

This implements the plumbing from the wayland text input protocol to ibus. It then also implements a wayland compatible way of presenting the candidate popup.

It's pretty much the GNOME Shell implementation but with the quirk that we do our popup in GTK4 in the daemon.

The candidate popup is built in gtk4 in the daemon so we can do everything with it that GTK4 can do. I decided for now to pretty much 1:1 replicate the gnome one. All of the communication between the daemon and the compositor regarding the actual contents is handled by IBus so we only have to position the popup correctly.

For the popup to be positioned correctly GTK and all other apps have to use the wayland text input protocol as IM module and not IBus directly. While using ibus directly would also work we would have to add some additional communication between daemon and gala and since the wayland protocol is the future and already supported in GTK3 and 4 and used by default if no environment variable is set, I decided to not do that.
However currently something sets GTK_IM_MODULE=ibus and I can't figure out what :( So to test you currently have to start an app with the override GTK_IM_MODULE=wayland.

Kooha-2026-03-26-19-30-45.mp4

Fixes #2529 (at least the candidate popup, the properties are still not shown but I think we should handle them in the keyboard indicator just like GNOME does).

Also first step towards implementing an OSK

[leolost2605]

@ryonakano @danirabbit this should be ready now. I have tested it with the typing booster and pinyin (because for some reason mozc is by default still latin and to change it you need the property bar which we still don't have) however since I don't use input methods any feedback from someone who does would be great :)
Also any feedback on the popup design is appreciated though I'd prefer to maybe iterate in follow ups if there's nothing major.
And last but not least opinions on the following would be appreciated (i.e. if it's ok to not support ibus directly) (taken from the description):

For the popup to be positioned correctly GTK and all other apps have to use the wayland text input protocol as IM module and not IBus directly. While using ibus directly would also work we would have to add some additional communication between daemon and gala and since the wayland protocol is the future and already supported in GTK3 and 4 and used by default if no environment variable is set, I decided to not do that.
However currently something sets GTK_IM_MODULE=ibus and I can't figure out what :( So to test you currently have to start an app with the override GTK_IM_MODULE=wayland.

Also if somebody knows what sets GTK_IM_MODULE that would be great :)

[ryonakano]

@leolost2605 Thank you very much for your hard work on this! 🎉

I tested this branch with ibus-mozc and enabling it shows the candidate window as expected:

Also any feedback on the popup design is appreciated though I'd prefer to maybe iterate in follow ups if there's nothing major.

I'm 👍 with the current design, but it looks like the up/down button in the bottom of the popover does nothing for me.

Also if somebody knows what sets GTK_IM_MODULE that would be great :)

im-config seems to set GTK_IM_MODULE=ibus and running sudo apt purge im-config unsets it as you can see in the above screenshot.

Originally from https://gihyo.jp/admin/serial/01/ubuntu-recipe/0859#sec7_h1:

Ubuntuの場合、GTK_IM_MODULEはim-configパッケージで指定しているため、これを削除して再起動すればいいということになります。

translated into English:

GTK_IM_MODULE is set by im-config package on Ubuntu, so just removing it and restarting the system works fine.

[danirabbit]

It looks like on other platforms it's common to have a number by each suggestion. Is that a feature we just don't have yet?

It also looks like on several other platforms the options are layed out horizontally which looks nice and compact I think. But I agree that iterating on the design can be done in future branches and I'd prefer to have the functionality merged

[ryonakano]

It also looks like on several other platforms the options are layed out horizontally which looks nice and compact I think.

FYI it's common to be layed out vertically in case of Japanese input—AFAIK Windows, macOS, and Ubuntu goes to this route. This is how it looks like on macOS:

Also, macOS provides an option to change orientation in case of Chinese input:

Considering these things the orientation that people feel accustomed might be different per person or their language, so providing an option to change orientation would be nice. But I also agree with Dani that tweaking design can be done in succeeding PRs.

[Nyaacinth]

Thanks for this implementation (or fix) of ibus usage with elementary. 🤗
About the candidate layout, actually Chinese and Japanese speakers have different preferences on this. (I don't know how Korean speakers think, because I only speak Chinese, English, and Japanese.) I remembered that in ibus, mozc sets vertical and libpinyin sets horizontal by default. There might be an interface to get input method preferences in ibus somewhere since those settings are in each IM's own settings. (I agree this should be in some of the following PR's, and I'm saying this only to provide some info.)

[leolost2605]

Sorry for the delay to follow up I unfortunately lost access to my laptop :/
Regarding the orientation, we do already get the orientation from ibus as one of vertical, horizontal or system. Pinyin for example explicitly requests horizontal and how that looks can be seen in the video above. System is currently vertical for us because GNOME did it like that but ig we can change it to horizontal.
Regarding the numbers for the candidates, we get labels from ibus that we use but if they are null we fall back to numbers and how that looks can also be seen in the video above. Ig mozc doesn't send null but empty strings so we probably should check for that too? Or should we treat this as explicit intent to show no labels?

[ryonakano]

Ig mozc doesn't send null but empty strings so we probably should check for that too? Or should we treat this as explicit intent to show no labels?

Not sure if that is intentional, but as far as I tested on Fedora 43 Workstation, GNOME shows numbers even if mozc:

[leolost2605]

Once again sorry for the delay, I got my new laptop today.

Not sure if that is intentional, but as far as I tested on Fedora 43 Workstation, GNOME shows numbers even if mozc:

Ok I updated it to also fall back to the default labels if there's an empty string.

I hope I addressed every feedback but lmk if I missed some. This should be ready for review again :)

[ryonakano]

I'm sorry for my late review. Tested again and left two comments for the previous discussions.

[ryonakano]

Works for me with ibus-mozc and ibus-pinyin, thank you for your hard work on this!

I'm not familiar with the code base so another review from familiar member is appreciated.

[danirabbit]

Approve for UX team. Thanks for working on this!