Is it possible to package fcitx engines with flatpak ?

subins2000 commented 4 years ago

Hi

I would like to know if it is possible to package fcitx input engines with flatpak and distribute easily to users. I've understood ibus engines can't interact with host ibus from flatpak sandboxed environment : https://github.com/flatpak/flatpak/issues/3019

Distribution with flatpak will help ship fcitx engines easily

wengxt commented 4 years ago

I think: Use fcitx + flatpak app is possible. Use flatpak fcitx + flatpak fcitx engine + flatpak/host app is possible. Use host fcitx + flatpak fcitx engine would never be possible (at least due to inconsistency in version).

There's another people already did this to package fcitx into a flatpak package. FYI: https://github.com/fcitx/fcitx5/issues/99

One option is to package fcitx and all engine together into one big package. I think that's the case in the issue above (his issue is related to a xdg-dbus-proxy bug). So for now you need to -DUSE_SYSTEMD=Off when building fcitx5.

But I noticed that flatpak is able to have things like GL platform to work like a plugin to another flatpak package, I think it's might possible to even pack fcitx engine separately.

subins2000 commented 4 years ago

One option is to package fcitx and all engine together into one big package.

Interesting, how would the config be then ? Like this ?

export QT_IM_MODULE=flatpak run com.fcitx

I think it's might possible to even pack fcitx engine separately.

I would like to test this, which engine would you recommend for a newbie (to fcitx) to test packaging ? (I can only read English and Malayalam btw)

wengxt commented 4 years ago

im module is irrelevant to the server. To sum it up:

Depending on the actual protocol (Currently the most usable on is im module coming from input method project) IM Module (fcitx5-qt, fcitx5-gtk) need to be loaded by the application. Which means native app need to have it installed to use fcitx. flatpak app's runtime need to include IM Module to use fcitx (which already happens).

Application load im module as plugin, then send data to fcitx server by some protocol (dbus, X11, wayland etc), fcitx load "engine" as plugin, process the data, and return by to the application.

So as you can see, "engines" (fcitx5-anthy, fcitx5-kkc, fcitx5-chinese-addons etc) are the plugin to fcitx. im module is the plugin to the actual application. All of these "plugins" are based on shared library which means they need to be on the same platform.

As for package the library separately, you need to investigate how to load the plugin from another flatpak package. Maybe try fcitx5-m17n first based on the language you know. I think this is what you need : https://github.com/flatpak/flatpak/wiki/Extensions

tinywrkb commented 4 years ago

@subins2000 have a look here. This is pretty working correctly as far as I can tell, except:

~~Mozc is completely broken, though I experienced the same issue on my system even with the distro package.~~ fixed
Not all the icons in the system tray appears correctly. This is due to a flatpak-builder requirement for exported icon file naming. It can be worked around by patching Fcitx, its engines, and renaming the icons, something that I already did but I most probably missed some icons.

Probably the main issue is that the Flatpak runtime will still be stuck with the same Fcits widget toolkit IME modules. Maybe this doesn't matter if Fcitx keeps API compatibility but it would have been better if the widget toolkit IME modules would have been Flatpak runtime extensions that could be updated separately from the runtime, maybe even allow the user to choose the IME module version, something like what is possible with Mesa.
You can actually get similar behavior by using filesystem override to give Flatpak apps access to the toolkit widget IME module from the Fcitx5 Flaptak app and an environment variable, e.g. GTK_IM_MODULE_FILE.

I don't really keep my Flatpak manifests for Fcitx5 and its IME engines updated. Maybe when there will be a stable release.
I'm not a heavy user of Fcitx, I just slowly learning Chinese so I thought it would be useful.

p.s. I'm also trying to package IBus but something doesn't really work and I haven't debugged this yet. The WIP is in my ibus branch.

wengxt commented 4 years ago

mozc need to start a separate process mozc_server. It's likely that the path is not correctly set during the build time. --server_dir need to be passed to the build_mozc.py script.

The as of im module part, latest fcitx4 im module is compatible with fcitx5. (in the sense of dbus interface). Any combination of fcitx 4 or 5 server can be combined with fcitx 4 / 5 im module. (latest fcitx 4 required)

And GTK_IM_MODULE can be simply set to fcitx, no need to set to fcitx5.

tinywrkb commented 4 years ago

@wengxt Thank you for the detailed answer.

I'll look again later at Mozc and try your suggestion.

Note that I mentioned GTK_IM_MODULE_FILE not GTK_IM_MODULE and by that, I meant doing something like this:

# enter to a new gedit app sandbox session and give filesystem permission (read-only) to access the path where Flatpak applications are installed, specifically where Fcitx5 is installed
flatpak run --command=sh --filesystem=~/.local/share/flatpak:ro org.gnome.gedit

# in the sandbox session let's generate immodules.cache
export LD_LIBRARY_PATH=$HOME/.local/share/flatpak/app/org.fcitx_im.fcitx5/current/active/files/lib
export GTK_PATH=$HOME/.local/share/flatpak/app/org.fcitx_im.fcitx5/current/active/files/lib/gtk-3.0/3.0.0
gtk-query-immodules-3.0 > downloads/tmp/immodules.cache
export GTK_IM_MODULE_FILE=$HOME/downloads/tmp/immodules.cache
gedit &

And after we have immodules.cache in hand we just need to set global Flatpak overrides with the filesystem permission, the environment variables, and then we can start all our Flatpak apps as usual and the updated IME module will just be picked up.

tinywrkb commented 4 years ago

@wengxt setting --server_dir fixed the issue with Mozc and it's now working correctly. Thanks again ;)

wengxt commented 4 years ago

@tinywrkb if you can have any changes that you'd like to be put upstream, feel free to send pull request.