Add other im module for input method
wengxt opened this issue · 11 comments
Hi,
I'm the author of http://github.com/fcitx/fcitx/ , I wonder what can be done if a flatpak app want to use fcitx in the application?
Currently freedesktop-sdk-images/org.freedesktop.Sdk.json.in hardcode ibus's im module in the config, is this the only way to do this?
We added ibus since it now has a portal and is safe in a sandboxed environment. I guess we could add other modules, but we won't add unsafe ones. I guess fcitx talks to some host service too, like ibus?
Yeah, the immodule of fcitx can use either session dbus or a private dbus server. The dbus interface is quite similar to ibus.
So I assume that I'll need to add something like org.freedesktop.portal.Fcitx and only expose the input context related feature on it?
Yeah.
Nothing that allows one client to see or affect other clients.
Ideally in a different process, or at least a separate dbus connection.
Ok, anyway now I have a working test case.
https://gist.github.com/wengxt/892c83833b73fed26de4bb0f23c924d1
Any just to let you know that using a separate portal does not make ibus any safer. FYI: ibus/ibus#1955
I already prevented such thing from happening in fcitx.
Ping? Is there any other you'd need from fcitx side?
I'm still not convinced we want to support multiple input method frameworks
What do you mean by "we"? Is your "we" "GNOME"?
I know GNOME has no intention to support multiple input method frameworks. But as for a flatpak application itself, the problem is not about GNOME only. It is about that the outside world user can use their prefered input method framework or not. And just FYI fcitx itself is default at least for Chinese on many distros (Ubuntu 16, and some Chinese ubuntu flavor, opensuse, debian), even though gnome decides to solely support ibus long time ago.
I would say the best solution is to make im module a flatpak extension and let user install it. The problem is immodule.cache file need to be updated accordingly otherwise Gtk will not be able to pick it up. I'm not familiar with flatpak so I don't know if there could be a trigger to run before launch the application to generate the immodule.cache and set GTK_IM_MODULE_FILE point to that file accordingly.
I'd be happy to go with that route if there's such a solution.
"I" means myself, as the gtk maintainer, "we" means the group of people working on flatpak (which I'm a member of).
I am pretty convinced that input modules were a strategic mistake and have cemented the fragmentation that is already prevalent in this space and made everybody write their own im framework (xim, iiimf, ibus, fcitx,... who can count them).
For GTK+ 4, I am considering dropping loadable modules for this, and just including a 'platform' module for each platform.
People write their own im framework is not because of im module. I hope you understand that. There are different design decisions behind the different input method framework. And that's why people are still doing different framework.
As for Gtk+, people write different im module is simply because there is no usable generic protocol that satisfies the requirements. XIM is synchronous, can't support right input window position, causes application freeze, and is as buggy as hell in certain application (XIM + gtk + chromium -> barely work at all).
If you'd take sometime read my blog post about the situation (https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/), the wayland input method protocol is not even any better than XIM. For XIM, at least it is widely adopted.
X11 / Xwayland will still exists for some time and people still need to use input method under it. And your argument does NOT solve any problem today, not to mention Gtk 4 is not out yet. The im module will still be able to carry rich information to the application to make input method better for users while the generic protocol is still not usable yet.
Even all arguments above are off-topic.
The Actual problem is: my users who are using fcitx today can't type within gtk3 flatpak applications. How can we solve this problem for them?