bug: fcitx5 input method cannot be used in GUIs launched via systemd units

Yorwba commented 2 years ago

Are you following the right branch?

[X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

[X] I have searched the existing issues

Issue description

In my ~/.config/nixpkgs/home.nix I have

{
  # ... other options omitted
  i18n.inputMethod = {
    enabled = "fcitx5";
    fcitx5.addons = with pkgs; [
      fcitx5-chewing
      fcitx5-chinese-addons
      fcitx5-hangul
      fcitx5-mozc
    ];
  };

  programs.gnome-terminal = {
    enable = true;
    profile."..." = {
       # ...
    };
    showMenubar = false;
  };

  services.kdeconnect = {
    enable = true;
    indicator = true;
  };
}

which I would expect to allow me to use fcitx5 to type in various languages when using GUI programs like gnome-terminal or selecting "Configure..." in the kdeconnect-indicator tray icon menu.

However, when using these programs, the fcitx5 keyboard switching shortcut has no effect and the fcitx5 tray icon remains blank instead of showing the currently selected keyboard layout.

With other programs like firefox, gedit and even kdeconnect-settings, using fcitx5 works fine.

Comparing the /proc/$PID/environ of the kdeconnect-indicator and kdeconnect-settings processes, I noticed that the kdeconnect-indicator was missing the three environment variables added to home.sessionVariables by fcitx5.nix, probably because kdeconnect-indicator is launched as a systemd unit.

So I used systemctl --user edit kdeconnect-indicator to create a ~/.config/systemd/user/kdeconnect-indicator.service.d/override.conf file with the following content:

[Service]
Environment="GTK_IM_MODULE=fcitx"
Environment="QT_IM_MODULE=fcitx"
Environment="XMODIFIERS=@im=fcitx"

Then I was able to use fcitx5 in the kdeconnect configuration window.

Trying the same for the gnome-terminal-server unit didn't work, though using "GTK_IM_MODULE=xim" did. It seems like gnome-terminal-server is unable to locate the fcitx5 input method module for GTK.

Stracing gedit, it successfully locates the module via the immodules.cache under ~/.nix-profile:

access("/run/current-system/sw/etc/gtk-3.0/immodules.cache", F_OK) = -1 ENOENT (No such file or directory)
access("/nix/var/nix/profiles/default/etc/gtk-3.0/immodules.cache", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/profiles/per-user/yorwba/etc/gtk-3.0/immodules.cache", F_OK) = -1 ENOENT (No such file or directory)
access("/home/yorwba/.nix-profile/etc/gtk-3.0/immodules.cache", F_OK) = 0
openat(AT_FDCWD, "/home/yorwba/.nix-profile/etc/gtk-3.0/immodules.cache", O_RDONLY) = 12
newfstatat(AT_FDCWD, "/nix/store/wqgz939h2zqw0ymvxk9j02dn8r94fl2y-fcitx5-with-addons-5.0.15/lib/gtk-3.0/3.0.0/immodules/im-fcitx5.so", {st_mode=S_IFREG|0555, st_size=136280, ...}, 0) = 0
openat(AT_FDCWD, "/nix/store/wqgz939h2zqw0ymvxk9j02dn8r94fl2y-fcitx5-with-addons-5.0.15/lib/gtk-3.0/3.0.0/immodules/im-fcitx5.so", O_RDONLY|O_CLOEXEC) = 12

while gnome-terminal-server doesn't even look there:

openat(AT_FDCWD, "/nix/store/44xm8jba98mviq4fnac2qn6rbrlj54x4-gtk+3-3.24.34/lib/gtk-3.0/3.0.0/immodules.cache", O_RDONLY) = 11

It seems like some additional plumbing is required to tell graphical programs launched by systemd units about input method engines like fcitx5.

Maintainer CC

@Kranzes @kamadorueda @adisbladis @rycee

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.18.15, NixOS, 22.05 (Quokka), 22.05.2167.a9f66ae6401`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.8.1`
 - channels(root): `"nixos-22.05"`
 - channels(yorwba): `"home-manager-22.05.tar.gz"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

stale[bot] commented 1 year ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

koiuo commented 1 year ago

I wanted to report similar bug.

As you've pointed out, the issue is that user's environment isn't passed to kde-connect.

Looks like home-manager should track environment variables it sets, and then propagate those into user's systemd units.

Do you want to rename your issue to indicate that the issue is caused by the environment not being propagated? IMO, it may sound less intimidating and more urgent to potential contributors.