Adding GTK4 IM modules to support IME frameworks in Wayland about com.google.chrome

[refi64]

Is there a bug filed for the runtime to add this yet? I wouldn't mind adding it here if there's no plans to add it to 21.08 / has an undefined timeline, but if it's coming relatively SOON(tm) I don't want to end up with an accidentally slightly incompatible version or something.

[tinywrkb]

No, I haven't reported it myself and didn't see a relevant bug report.

I wasn't sure if the devs would agree to add GTK4 and other libraries to the 21.08 runtime, and it already has libfcitx4 which conflicts with libfcitx5, or at least when using the buildsystem installation target (overwrites some .so symlinks). edit: I dropped libfcitx5, it's not needed for building the module
It's likely possible to add the GTK4 Fcitx5 IM module to the runtime and not affect the exiting GTK3 Fcitx4 module, but it's not the approach I would choose.

An extension that can be reused seems like a good temporary solution until the 22.08 runtime will be available.

I haven't looked at IBus yet, so I can't comment about it.

Anyway, I hoped to get here some feedback, and maybe move this extension solution forward.

Note the existing issues:

• Fcitx5 module: No popups, so no candidate box. Maybe it's working in Gnome with the Kimpanel extension.
• IBus module: Wrong popup location

[tinywrkb]

I added the GTK4 IBus IM module, and at first glance it works correctly, even though gio-querymodules doesn't add it to giomodule.cache.

Fcitx5 has a IBus backend, so it's possible to use the IBus IM module with the Fcitx5 daemon.
The reason one would want to do this is to take advantage of the working popups while still using Fcitx5.
edit: And this is exactly what I'm doing, as I'm running my own updated build of the Fcitx5 Flathub app, testing the ChineseAddons and Hangul extensions (the latter not on Flathub yet).

[tinywrkb]

I looked at this again today, and confirmed that Chrome uses GTK4 at least also for the system printing popup window.
The GTK3 CUPS printing backend, and libcups are already bundle in this app and others (some Electron based), so the Flatpak extension approach might not be the best solution, even if makes it possible to avoid bundling GTK4 in every Chromium based app.

The handful Chromium based browsers and CEF based apps can build and package GTK4, the IM modules, and printing backends, if needed.
Electron based apps, if this framework supports GTK4, will be able to use GTK4 and its modules from the base app.

I updated the packaging, and now it's pretty minimal, building and installing just needed dependencies and features.

Other possible changes that can be made:

• Enable the GTK4 CUPS backend. Especially if it's decided to go forward with bundling the IM modules in the Flatpak app here.
• Don't build updated GTK3 IM modules.
• Avoid installing ECM by building it with the Fcitx5 GTK4 modules. See example.

If it's decided to bundle GTK4 and the IM modules in the app, then I can send a PR.

[tinywrkb]

I've been testing with Chrome dev builds, so I haven't noticed that we need to wait for Chrome 97, so a PR with my changes won't help much without switching release channel.

I sent a PR to the Edge app, and it's working there, as the Beta channel is on 97.

CUPS backend is also packaged now and working.

[tinywrkb]

Oh! Stable due date is today. I'll send a PR.

[tinywrkb]

Closing in favor of adding to Chromium base app.