fcitx5: `fcitx5-with-addons` should wrap other commands

Update:

I realized that my understanding of the "bug" initially described on this issue was wrong.

The issue I have is that fcitx5-with-addons only wraps around fcitx5, so other commands would be oblivious to addons on the system. See https://github.com/NixOS/nixpkgs/issues/160437#issuecomment-1042755001

An example of when this can be problematic:

Configure Fcitx to use an IME provided by an addon, like Mozc
Start Fcitx with fcitx5-remote or fcitx5-configtool
Mozc won't be recognized as a valid input method, and will be deleted from your config

Also, you just won't be able to use Mozc in this scenario until you kill the Fcitx process and start it again "properly".

Old stuff:

Describe the bug

fcitx5's Addon Config Dir seems to default to /nix/store/<fcitx5>/share/fcitx/addon instead of /nix/store/<fcitx5-with-addons>/share/fcitx5/addon/.

Steps To Reproduce

Steps to reproduce the behavior:

Install fcitx5 by setting i18n.inputMethod.enabled = "fcitx5"

This can be confirmed by the outputs of fcitx5-diagnose:

$ fcitx-diagnose
<omitted>
# Configuration:
## Fcitx Addons:
1.  Addon Config Dir:

    Found fcitx5 addon config directory: `/nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon`.
<omitted>

Expected behavior

It should instead default to /nix/store/<fcitx5-with-addons>/share/fcitx5/addon/, as it would break optional plugins like fcitx5-mozc.

Additional context

Content of fcitx5:

$ ls -lA /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon
total 72
-r--r--r-- 2 root root 586 Jan  1  1970 classicui.conf
-r--r--r-- 2 root root 399 Jan  1  1970 clipboard.conf
-r--r--r-- 2 root root 271 Jan  1  1970 dbus.conf
-r--r--r-- 2 root root 356 Jan  1  1970 dbusfrontend.conf
-r--r--r-- 2 root root 320 Jan  1  1970 fcitx4frontend.conf
-r--r--r-- 2 root root 350 Jan  1  1970 ibusfrontend.conf
-r--r--r-- 2 root root 666 Jan  1  1970 imselector.conf
-r--r--r-- 2 root root 358 Jan  1  1970 keyboard.conf
-r--r--r-- 2 root root 480 Jan  1  1970 kimpanel.conf
-r--r--r-- 2 root root 779 Jan  1  1970 notificationitem.conf
-r--r--r-- 2 root root 646 Jan  1  1970 notifications.conf
-r--r--r-- 2 root root 369 Jan  1  1970 quickphrase.conf
-r--r--r-- 2 root root 278 Jan  1  1970 spell.conf
-r--r--r-- 2 root root 817 Jan  1  1970 unicode.conf
-r--r--r-- 2 root root 275 Jan  1  1970 wayland.conf
-r--r--r-- 2 root root 464 Jan  1  1970 waylandim.conf
-r--r--r-- 2 root root 210 Jan  1  1970 xcb.conf
-r--r--r-- 2 root root 595 Jan  1  1970 xim.conf

Contents of fcitx5-with-addons with fcitx5-mozc installed:

$ ls -lA /nix/store/24p7w05im9zfa29c4vl4rsmm38xb3pxs-fcitx5-with-addons-5.0.14/share/fcitx5/addon/
total 0
lrwxrwxrwx 2 root root 91 Jan  1  1970 classicui.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/classicui.conf
lrwxrwxrwx 2 root root 91 Jan  1  1970 clipboard.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/clipboard.conf
lrwxrwxrwx 2 root root 86 Jan  1  1970 dbus.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/dbus.conf
lrwxrwxrwx 2 root root 94 Jan  1  1970 dbusfrontend.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/dbusfrontend.conf
lrwxrwxrwx 2 root root 96 Jan  1  1970 fcitx4frontend.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/fcitx4frontend.conf
lrwxrwxrwx 2 root root 94 Jan  1  1970 ibusfrontend.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/ibusfrontend.conf
lrwxrwxrwx 2 root root 91 Jan  1  1970 imeapi.conf -> /nix/store/hzkw9j6h3zdgbnq0nxc1xwc85q7b8nkm-fcitx5-lua-5.0.6/share/fcitx5/addon/imeapi.conf
lrwxrwxrwx 2 root root 92 Jan  1  1970 imselector.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/imselector.conf
lrwxrwxrwx 2 root root 90 Jan  1  1970 keyboard.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/keyboard.conf
lrwxrwxrwx 2 root root 90 Jan  1  1970 kimpanel.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/kimpanel.conf
lrwxrwxrwx 2 root root 99 Jan  1  1970 luaaddonloader.conf -> /nix/store/hzkw9j6h3zdgbnq0nxc1xwc85q7b8nkm-fcitx5-lua-5.0.6/share/fcitx5/addon/luaaddonloader.conf
lrwxrwxrwx 2 root root 98 Jan  1  1970 mozc.conf -> /nix/store/vwiaxsza9s8xmw1r1vdyjcmdmwyll07q-fcitx5-mozc-2.26.4220.102/share/fcitx5/addon/mozc.conf
lrwxrwxrwx 2 root root 98 Jan  1  1970 notificationitem.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/notificationitem.conf
lrwxrwxrwx 2 root root 95 Jan  1  1970 notifications.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/notifications.conf
lrwxrwxrwx 2 root root 93 Jan  1  1970 quickphrase.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/quickphrase.conf
lrwxrwxrwx 2 root root 87 Jan  1  1970 spell.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/spell.conf
lrwxrwxrwx 2 root root 89 Jan  1  1970 unicode.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/unicode.conf
lrwxrwxrwx 2 root root 89 Jan  1  1970 wayland.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/wayland.conf
lrwxrwxrwx 2 root root 91 Jan  1  1970 waylandim.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/waylandim.conf
lrwxrwxrwx 2 root root 85 Jan  1  1970 xcb.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/xcb.conf
lrwxrwxrwx 2 root root 85 Jan  1  1970 xim.conf -> /nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/share/fcitx5/addon/xim.conf

Notify maintainers

@poscat0x04, I guess?

Metadata

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.16.7, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.6.0`
 - channels(root): `"nixos"`
 - channels(plumeus): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

There is a wrapper under fcitx5-with-addons which set environment variable FCITX_ADDON_DIRS to the external addons dir.

And the fcitx5-diagnose is a simple bash script which is not set such variable and doesn't check that environment variable so this dir is not printed by it.

If you want to ensure whether an addon is loaded, please check the output of fcitx5 (stdout, systemd log or others)

P.S. Addons such as rime and chinese-extra-addons can work in the master branch which is tested in prs. Mozc should be the same.

I suggest you rebuild your nixos again and then, restart fcitx5 daemon (systemctl restart --user fcitx5-daemon. systemctl reload may also be needed.) if you use the default service or do things like this.

If you use fcitx5 -r to open a new fcitx5 service, you should make sure that fcitx5 is not the old one by realpath $(which fcitx5)

Hmm, okay. I just assumed the fcitx5-diagnose was doing it's job.

Using the default service by systemctl <command> --user works, yes. I wasn't aware of this and manually started the process with fcitx5-remote, and in that case, mozc doesn't seem to be loaded.

For starting it manually, it seems like starting Fcitx with fcitx5 --enable mozc seems to make mozc available.

I made sure I did pkill fcitx5 every time I started a new Fcitx instance to test for behavior.

Edit:

So, clearly, my original understanding of the "bug" was wrong. Now my question is, is it intended behavior for Mozc (and presumably other addons) to not be loaded when running it manually?

I find this annoying because if I'm understanding this right, if I ever accidentally start Fcitx manually, Mozc will be considered an invalid input method and thus would be deleted from my configs, and I would need to reconfigure it again.

I find this annoying because if I'm understanding this right, if I ever accidentally start Fcitx manually, Mozc will be considered an invalid input method and thus would be deleted from my configs, and I would need to reconfigure it again.

I update my fcitx5 and mozc to the master branch and Mozc is loaded by automatically.

modify some files and then nix flake update github:NixOS/nixpkgs/master
nixos-rebuild --flake '...'
fcitx5 -r (This is only needed if you have run a fcitx5, otherwise fcitx5 is enough.)
fcitx5-config-qt, mozc is found.

Now everytime system is booted, the fcitx5-mozc is loaded automatically.

~~> I wasn't aware of this and manually started the process with fcitx-remote, and in that case, mozc doesn't seem to be loaded.~~

~~Sorry, I don't know how to start fcitx5 by fcitx5-remote.~~

~~For the realpath, you can try cat $(which fcitx5) | grep ADDONS and then here is the dir.~~

Now my question is, is it intended behavior for Mozc (and presumably other addons) to not be loaded when running it manually?

There is no problem for me when mannually starting a service by fcitx5 -d (daemon), fcitx5 (front ground), or fcitx5 -r (replace the current service).

~~How do you start your fcitx5?~~ If you use systemd user service, the reason probably is that the old service is not restart or replace by the new one (the path of fcitx5 must be updated which is different from other distrubtions). In this case, you can try systemctl daemon-reload && systemctl restart --user fcitx5-daemon (this will break some application to use input method due to the old process is killed.) or just reboot your system.

If you are using gnome or kde, autostart may also start a fcitx5 (/run/current-system/sw/etc/xdg/autostart/org.fcitx.Fcitx5.desktop). In this cases, you should kill that process and restart fcitx5 to ensure the new wrapper is used. In addition, you have to disable systemd service to avoid confliction.

Edit: I think you'd better check whether there is a running fcitx5 process and it is really killed, whether fcitx5 is started with the wrapper which involves mozc and whether the old autostart or systemd service is used.

Or simply, have you tried to reboot your pc? This can escape from killing process or restarting service manually. If you don't want to reboot, I suggest you stop your systemd service by systemctl stop --user fcitx5-daemon (or disable the i18n.inputmethod... or systemd.user.services.fcitx5-daemon), kill all other fcitx5 process and then open a new terminal with the newest fcitx5 containing fcitx5-mozc (checked by realpath ... or cat $(which fcitx5 | grep ADDON). Now, start fcitx5 and check mozc again. If it still doesn't exist, you can try to replace fcitx5 with fcitx5 --verbose ... to see the output about loading addons.

How do you start your fcitx5?

I've been using fcitx5-remote because... well, I didn't know what to do. Should've used fcitx5 in hindsight

I rebooted my system to make sure that's not the issue, and I think I finally have a better understanding of what's going on.

$ realpath $(which fcitx5)
/nix/store/24p7w05im9zfa29c4vl4rsmm38xb3pxs-fcitx5-with-addons-5.0.14/bin/fcitx5

$ realpath $(which fcitx5-remote)
/nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/bin/fcitx5-remote

$ realpath $(which fcitx5-configtool)
/nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/bin/fcitx5-configtool

$ realpath $(which fcitx5-diagnose)
/nix/store/gzvzx5cz4s15g4dkg8vyn960v8smmkc4-fcitx5-5.0.14/bin/fcitx5-diagnose

$ realpath $(which fcitx5-config-qt)
/nix/store/7ar2w3i2w6bba5ndq5hndd2d7q89vsjb-fcitx5-configtool-5.0.11/bin/fcitx5-config-qt

It seems like the one with addons isn't called when I start Fcitx using anything but fcitx5 ~~(and fcitx5-config-qt?)~~. So, using fcitx5-configtool before Fcitx has started, and clicking on this prompt would cause the issue I described above:

I think it's somewhat plausible that a person might attempt to run fcitx5-configtool when fcitx5 isn't running, click that button without knowing the consequences, and get burned.

It seems like Mozc doesn't load when I start Fcitx using anything but fcitx5 (and fcitx5-config-qt?). So, using fcitx5-configtool before Fcitx has started, and clicking on this prompt would cause the issue I described above:

You can run cat $(which fcitx5) and cat $(which fcitx5-configtool). It is the reason why addons cannot be found if fcitx5 is started by fcitx5-configtool. fcitx5-configtool executes qt or gtk config binary without the addons' wrapper. In these executors, they run the original fcitx5 (absolute path determined during build) instead of the one in PATH. The fcitx5 in PATH is a wrapper involving FCITX_ADDON_DIR which pass the external addons dir to fcitx5. Any other methods such as systemd services uses the wrapper to start fcitx5 but fcitx5-configtool not.

If you want to make fcitx5-configtool working as your proposal, you can wrap other scripts like fcitx5 in fcitx5-with-addons. PR is welcome.

If you want to make fcitx5-configtool as your proposal, you can wrap other scripts like fcitx5 in fcitx5-with-addons. PR is welcome.

Yep, I was just arguing that the status quo seemed like a foot-gun, and questioning whether this is intended behavior. I'd be fine opening a PR.

I guess I'll rename this issue to something like "fcitx5-with-addons should wrap other commands" and change the original post to reflect that? If that's not considered a bug, I guess this issue can be closed until I (or somebody else) makes a PR.

NixOS / nixpkgs