Nixpkgs: fcitx input method do not work on unstable and 16.03

Created on 18 Mar 2016 · 28Comments · Source: NixOS/nixpkgs

Basic info

To make sure that we are on the same page:

Kernel: Linux Silicate 4.4.4 #1-NixOS SMP Thu Mar 3 23:10:04 UTC 2016 x86_64 GNU/Linux
System: 16.09pre78286.0bf8a1a (Emu)
Nix version: nix-env (Nix) 1.11.2
Nixpkgs version: "16.09pre78286.0bf8a1a"

Describe your issue here

I can use fcitx (everything works fine) if I do my nixos-rebuild after #11254 (I git-checkout that commit on nixos-unstable)
but it will not work if I use the latest nixos-unstable or nixos-16.03-beta.

My .xsession-errors have nothing different when fcitx is not working.

Expected result

The input method should be switched when I press ctrl-space.

Actual result

There is no response when I press ctrl-space.

Steps to reproduce

I use this configuration:

i18n = {
  consoleKeyMap = "us";
  defaultLocale = "en_US.UTF-8";
   inputMethod = {
      enabled = "fcitx" ; 
      fcitx.engines = with pkgs.fcitx-engines; [ hangul mozc anthy chewing table-other ];
  } ; 
};

@ericsagnes, thank you.

Source

sifmelcara

All 28 comments

Thanks for reporting!
I will try to fix this as soon as possible.

ericsagnes on 18 Mar 2016

@sifmelcara I did a quick test with 16.09pre78286.0bf8a1a and as far as I can tell it is working fine on my test machine.
As input methods are related to other parts of the system, the cause might be somewhere else.

Could you check the following?

Are there methods enabled in the fcitx settings? (settings can be opened by running fcitx-config-gtk3). Input methods has to be added in the Input Method list before they can be used.
In the same settings, on the Global Settings tab, you can check and change the default shortcuts for triggering and switching the input methods. You can try to change the shortcut to check if another application was already using ctrl+space.
if you use a system tray, is there the fcitx icon (keyboard looking icon) in it?
if you right click the system tray icon, a menu will open and you can change the input method from it. Does changing the input from there works?
ctrl+space is by default the trigger key, some methods like hangul need to press other keys to enable non alphabet input. You can try to use ctrl+shift to switch to another enabled input method to see if input is working there.
updating fcitx-mozc and not rebooting will sometimes make fcitx freeze for some time, and then display an alert complaining about mozc server already running. An easy fix is to restart the machine.
Fcitx uses special plugins for each application toolkit, it happens that sometimes there is a problem with a specific plugin and fcitx is not working with that toolkit. Can you try to use the shortcut in different toolkit applications (Qt4, Qt5, GTK2, GTK3) to see if any is working?

ericsagnes on 19 Mar 2016

@ericsagnes
I followed your suggestion and found that fcitx not works on gtk2/gtk3 applications only. (works on qt4 and native applications)

Thank you for your testing.

sifmelcara on 19 Mar 2016

@sifmelcara What are the applications that didn't worked?
I couldn't reproduce with gnome3.gedit (gtk3) and geany (gtk2) using mozc, hangul and chewing.

ericsagnes on 19 Mar 2016

@ericsagnes
gnome3.gedit, chromium, and firefox didn't work.
I can reproduce the problem if I make a new NixOS install.
I tested on none+xmonad, kde4 and kde4+xmonad, all of them break fcitx in gtk applications.

sifmelcara on 19 Mar 2016

  i18n = {
    # consoleFont = "Lat2-Terminus16";
    consoleKeyMap = "us";
    defaultLocale = "en_US.UTF-8";
    inputMethod = {
      enabled = "fcitx" ; 
      fcitx.engines = with pkgs.fcitx-engines; [ chewing ] ; 
    } ; 
  };
   environment.systemPackages = with pkgs; [
     wget
     vim
     gnome3.gedit
     terminator
   ];

  services.xserver = {
    enable = true;
    displayManager.kdm.enable = true ; 
    desktopManager.kde4.enable = true ; 
  } ; 

  users.extraUsers.sys9mm = {
    isNormalUser = true;
    home = "/home/sys9mm" ; 
    extraGroups = [ "wheel" "networkmanager" ] ;
  };

  # The NixOS release to be compatible with for stateful data such as databases.
  system.stateVersion = "15.09";
}

Above is the configuration that reproduce the problem.
steps:

rm -rf /home/sys9mm
mkdir /home/sys9mm ; chown sys9mm:users -R /home/sys9mm
login with kde4 desktop environment
open fcitx-config-gtk3 and add chewing to input method list
open konsole and gedit, then I can find that fcitx only works in konsole, but not gedit.

Thank you

sifmelcara on 20 Mar 2016

@sifmelcara ok, I found the cause but not yet a way to fix it.
i18n.defaultLocale being set to en_US.UTF-8 seem to be the cause, if set to something else like ja_JP.UTF-8, ctrl+space is working.
There is a mention about the locale set to english and ctrl+space not working in the archlinux wiki but no real directions on a fix other than setting the env variables that are already set in NixOS.

A quick workaround would be to use a locale other than english.

I will update the issue as soon as I find a real fix.

ericsagnes on 20 Mar 2016

I believe fcitx with gtk plugin was broken by some commit after your pull request #11254 got merged, because at that time fcitx works fine even I set i18n.defaultLocale = "en_US.UTF-8";.

sifmelcara on 20 Mar 2016

I've been having the same problem, and maybe was having the same problem with IBus recently, too. Anyway, after discussions on fcitx's IRC channel, it seems that the problem could be an invalid cache entry. For me, /nix/store/1ng2rcax0jzcqd0yazz53yspjmsl5s2h-gtk+-2.24.29/lib/gtk-2.0/2.10.0/immodules.cache contains entries which correspond to what I see in the context menu of this screenshot (lacking fcitx). That context menu can be found in file dialogs of gtk2 applications.

A partial workaround is to do the following.

$ nix-shell -p gnome.gtk
nix$ gtk-query-immodules-2.0 > $HOME/gtk2-immodule.cache
$ GTK_IM_MODULE_FILE=$HOME/gtk2-immodule.cache whatever-gtk2-app

It seems that this code tries to address the issue, but somehow fails.

laMudri on 21 Mar 2016

@ttuegel Could this issue be a side effect of a91161aa57f7cfe447a551bafc2d7c6c6bbbe44b ?

ericsagnes on 22 Mar 2016

@ericsagnes I suppose it must be, but I'm not seeing what happened right now. That commit didn't change the setting of GTK_IM_MODULE_FILE.

ttuegel on 22 Mar 2016

I think it's that this is run without the input method as a plugin. We shouldn't need to use GTK_IM_MODULE_FILE (it's insufficient, since different values are required for gtk2 and gtk3), and the problem is the existence of /nix/store/...-gtk+-2.24.29/lib/gtk-2.0/2.10.0/immodules.cache (and the 3.0 version) written without an IM being installed.

laMudri on 22 Mar 2016

Hi all, I'm current main developer of fcitx.

I'd just like to provides some of my knowledge here.

The immodules.cache file is a file that let gtk to find im module plugins. Without it, or outdated immodules.cache file will make gtk unable to find newly installed im modules.

Currently, it's being generated at https://github.com/NixOS/nixpkgs/blob/1a4ab04e298077185dd32d4594825b6e92f60a4e/pkgs/development/libraries/gtk%2B/2.x.nix#L43

But this is wrong for NixOS becauses nix provides read-only package. The file cannot be updated after you install any new im modules.

My theory for people who doesn't have this problem is that they build gtk after having fcitx immodule installed, thus this file is accidentally get updated by rebuilding.

The GTK_IM_MODULE_FILE mentioned about is just a temporarily workaround for him. Because gtk2 and gtk3 shares the same environment variable but they need to point to different file, so this env var can not be considered as a long term solution.

To me, the correct solution is to move this file out of the package, and update it upon install any new gtk im module. Though I have no knowledge what's the right way to implement it in nix package. May be some patch is needed to change the path to this file it currently resides in $libdir of gtk.

wengxt on 22 Mar 2016

🎉1

My theory for people who doesn't have this problem is that they build gtk after having fcitx immodule installed, thus this file is accidentally get updated by rebuilding.

That is not possible in Nix; each build is completely isolated. I don't have this problem with ibus, but I also have the XIM method enabled, which is probably why it works.

The GTK_IM_MODULE_FILE mentioned about is just a temporarily workaround for him. Because gtk2 and gtk3 shares the same environment variable but they need to point to different file, so this env var can not be considered as a long term solution.

This is not a big problem. It is already not possible to use GTK2 and GTK3 at the same time from Nix.

To me, the correct solution is to move this file out of the package, and update it upon install any new gtk im module. Though I have no knowledge what's the right way to implement it in nix package. May be some patch is needed to change the path to this file it currently resides in $libdir of gtk.

Yes, we could patch GTK to look for this cache file under /var somewhere. (This is the only mutable path in Nix.) In fact, we should do this for all the other types of GTK cache file. Unfortunately, this will only work for our users on NixOS, but users on other operating systems should use their own OS's input methods.

ttuegel on 22 Mar 2016

This is not a big problem. It is already not possible to use GTK2 and GTK3 at the same time from Nix.

What about using both, say, Firefox and gedit? I can't set GTK_IM_MODULE_FILE globally in such a way that both applications will work.

laMudri on 22 Mar 2016

What about using both, say, Firefox and gedit? I can't set GTK_IM_MODULE_FILE globally in such a way that both applications will work.

It is already not possible to install both applications simultaneously and have widget themes and image loaders working in both, see #5053.

ttuegel on 22 Mar 2016

Yes, we could patch GTK to look for this cache file under /var somewhere. (This is the only mutable path in Nix.) In fact, we should do this for all the other types of GTK cache file. Unfortunately, this will only work for our users on NixOS, but users on other operating systems should use their own OS's input methods.

AFAIK, to adapt normal unix software to work under nix os path scheme, there are already many patches/hacks/workarounds used right now. Moving cache file to somewhere persistent across reboot but writable looks necessary for NixOS to work with gtk2/3 + input method. I didn't mean that this patch should be upstreamed or something, this will be a NixOS specific patch obviously.

Well, I won't argue about NixOS decision (because I'm not a NixOS user), but I'd suggest that you guys can at least patch gtk3 to make the environment variable of gtk3 uses it own "prefix", e.g. changing it to GTK3_IM_MODULE_FILE. (and GTK3_DATA_PREFIX, for the case in your link). IMHO, coinstallability of gtk2/3 is still important right now.

FYI, Qt4 itself supports QT4_IM_MODULE.

wengxt on 22 Mar 2016

I didn't mean that this patch should be upstreamed or something, this will be a NixOS specific patch obviously.

Sorry, I meant, it will work if you're using Nix on NixOS, but it won't work if you're using Nix on Ubuntu or Nix on Arch (for example). Of course it won't be upstreamed.

Well, I won't argue about NixOS decision (because I'm not a NixOS user), but I'd suggest that you guys can at least patch gtk3 to make the environment variable of gtk3 uses it own "prefix", e.g. changing it to GTK3_IM_MODULE_FILE. (and GTK3_DATA_PREFIX, for the case in your link). IMHO, coinstallability of gtk2/3 is still important right now.

I agree with you 100%, and I have proposed that solution before, but it was rejected by the GTK maintainers because it breaks compatibility with upstream GTK.

ttuegel on 22 Mar 2016

I agree with you 100%, and I have proposed that solution before, but it was rejected by the GTK maintainers because it breaks compatibility with upstream GTK.

Or simply provides a wrapper script that calls gtk-query-im-modules-{2,3}.0 to generate a temp file and set GTK_IM_MODULE_FILE correspondingly for all gtk application.. I used this method for bundled firefox under ChakraOS when it still used bundle for gtk app.

That is not possible in Nix; each build is completely isolated. I don't have this problem with ibus, but I also have the XIM method enabled, which is probably why it works.

Probably, but just FYI, XIM is extremely outdated (90s), buggy (synchronous call everywhere, can easily freeze app if input method server quits), unmaintained (many TODOs in source which is never implemented for years), and lacks of important features comparing with what an native im module can provides, e.g. surrounding text support which is commonly used in Japanese input method.

wengxt on 22 Mar 2016

@ttuegel I can confirm that reverting a91161aa57f7cfe447a551bafc2d7c6c6bbbe44b on latest unstable fix the problem.
Should we do that as a quick fix for people depending on input methods until we have a cleaner fix?

I personally like @wengxt GTK3_IM_MODULE_FILE proposition, and I wonder if in the gtk3 builder it could be possible to enable it for only for NixOS so it won't affect nix users on other platforms?

ericsagnes on 26 Mar 2016

@ericsagnes OK, can we do a partial revert of a91161a by bringing back gtkPlugins only? I can tell you (as one of the Qt maintainers) that qtPlugins isn't necessary, breaks things for KDE users, and doesn't work in many cases anyway.

I personally like @wengxt GTK3_IM_MODULE_FILE proposition, and I wonder if in the gtk3 builder it could be possible to enable it for only for NixOS so it won't affect nix users on other platforms?

No, there isn't a way to determine NixOS vs. other Linux in the builder. We could patch GTK 3 so that it will fallback to GTK_IM_MODULE_FILE if GTK3_IM_MODULE_FILE is unset. If we're going to do this, we should also patch it for all the other environment variables it reads.

ttuegel on 26 Mar 2016

Previous discussion: #2450 #3275