add uim: A multilingual input method framework.

[taku0]

UIM is a multilingual input method framework (i.e. programs used to input Japanese, Chinese, Korean, and other complex languages) commonly used in Japan.
This patch adds UIM itself as well as configuration options for input method modules for GTK+ 2, GTK+ 3, and Qt 4. The options tell GTK+ and Qt where shared libraries of input modules are, so that GTK+ and Qt can cooperate with input methods.
Setting programs.uim.enable = true in the configuration file installs the UIM and configure GTK+ and Qt. Other input method frameworks such as Fcitx can utilise options gtk2ImModules, gtk3ImModules, and qtImModules to better cooperation with GTK+ and Qt.

[ghost]

We should not pass IMEs as buildInputs to gtk,
I'm afraid doing so people will have to build a lot of packages themselves.
Since hydra will not give the version with IME they want.

IMO, input methods should install im modules to its own out,
and then a gtk.immodules file can be built seperately (like loaders.cache of gdk-pixbuf)

[taku0]

Thank you for your comment. Lack of prebuild binaries is indeed an important problem. Rebuilding nearly all GUI applications whenever an IM is updated would be painful.
Meanwhile, we cannot use GTK+ 2 applications and GTK+ 3 applications simultaneously with a simple method. UIM provides different binaries for GTK+ 2 and GTK+ 3. As far as I know, the only way to specify different binaries for GTK+ 2 and GTK+ 3 is overriding ${gtk3}/lib/gtk-3.0/3.0.0/immodules.cache and ${gtk}/lib/gtk-2.0/2.10.0/immodules.cache. GTK+ 3 loads immodules.cache from those places:

• GTK_IM_MODULE_FILE environment variable,
• GTK_EXE_PREFIX/gtk-3.0/3.0.0/immodules.cache where GTK_EXE_PREFIX is a environment variable, or
• ${gtk3}/lib/gtk-3.0/3.0.0/immodules.cache.

GTK_IM_MODULE_FILE is shared by GTK+ 2 and GTK+ 3, so that we can not use it. GTK_EXE_PREFIX affects not only IM modules but also other modules.

Possible solusions:

• pass IMEs as buildInputs to gtk and gtk3 (my option)
• patch GTK+ to load immodules.cache from /etc, /run/current-system/sw/lib, or some other appropriate places
• patch GTK+ to load immodules.cache from different environment variables, that is, GTK2_IM_MODULE_FILE and GTK3_IM_MODULE_FILE

[ghost]

Thanks for clarification, you are right.

I'll vote for patching gtk.
@vcunat, what's your opinion?

[vcunat]

Hmm, it really surprises me that GTK_IM_MODULE_FILE only usable for setting it for a single program, but it's explicitly documented to be the case https://developer.gnome.org/gtk3/3.12/gtk-running.html

I would as well patch gtk+ to use those suggested variable names, as that's a simple change, and IMO it's unlikely to break anything (perhaps together with GTK_PATH and GTK_MODULES, which suffer from the same problem).

Other than this variable "collision", I find the situation similar to most plug-in frameworks: we certainly don't want to depend in build-time on the plugins chosen. It's tempting to set plugins by a system-wide environment variable, and it will mostly work, but some plugins just break if some dependencies differ (from those of the application using the plugin). I don't have a clue if input modules cause such problems, but e.g. gvfs/gio modules do have problems with some major updates. Technically it's best to have a generic wrapper package that combines chosen plugins into chosen app (ensuring deps. are the same), but it's currently cumbersome (I'm planning to make that user-friendly in future, but I expect it to need heavy nix-env changes).

[ghost]

Alternative, we can set GTK_EXE_PREFIX to the output of:

  gtk-runtime = buildEnv {
    name = "gtk-runtime";

    paths = [
      gtk2 gtk3 fcitx
     # and other modules like theme engine..
    ];

    postBuild = ''
      export GTK_EXE_PREFIX=$out
      rm $out/lib/gtk-2.0/2.10.0/immodules.cache # should done in gtk2
      $out/bin/gtk-query-immodules-2.0 > $out/lib/gtk-2.0/2.10.0/immodules.cache
      $out/bin/gtk-query-immodules-3.0 > $out/lib/gtk-3.0/3.0.0/immodules.cache
    '';

    ignoreCollisions = true;
  };

Then, both gtk2 and gtk3 will pickup the input methods.

[vcunat]

Also CC @lethalman.

[taku0]

I will vote for gtk-runtime. Fewer patching is preferable.

[ghost]

As mentioned by @vucnat, this approach require user to set system-wide environment variable, IIUC currently we have no easy way to provide tips for users.
Although it's a common feature of package manager:

• PKGBUILD of Archlinux do it in postinstall phase
• Guix will output some env setup if native-search-path is used by package

And because packages in user's profile usually come from different set of nixpkgs, the plugin and host package sometimes won't work toghther. I think we should port system profie's configuration model to user's profie.

• the core part of user-env build from a nix expr, just like configuration.nix for nixos, using options and config, and should contain the correct env vars setup in a profile for bash or something similary.
• the extra part is what nix-env do now, but we do not ensure the packages install by this way will works, and provide some tips for setup.

[taku0]

I have implemented @iyzsong's idea in #3275.

[lucabrunox]

I'd rather do what gdkpixbuf does. With a setup hook that sets GTK2_IM_MODULE_FILE and GTK3_IM_MODULE_FILE. All gtk programs are wrapped anyway to set the pixbuf variable, so it's about doing --set GTK_IM_MODULE_FILE "$GTK3_IM_MODULE_FILE" for gtk3 apps, similar for gtk2. That makes applications work outside nixos.

[taku0]

@lethalman
Is it means including uim as a direct/indirect depedency of the GTK+ applications? There are several input methods other than uim such as fcitx, SCIM, and IBus. Including all of them is possible but wasteful a bit, isn't it?

[lucabrunox]

@taku0 we always include, for example, gdk-pixbuf and librsvg. Can those input methods cohexist? It's that I don't like restricting usage of things to nixos, I'd like to make them work for nixpkgs too.
Rebuilding the world is secondary IMO to making things correct.

[taku0]

@lethalman Yes, we can install all input methods in a single computer. Users choose their IM by environment variables (GTK_IM_MODULE, QT_IM_MODULE, and XMODIFIERS).

[taku0]

Note that some input methods require to start daemons to support legacy X applications. Installing input methods by default increases running daemons on NixOS.

[taku0]

@lethalman
We don't need a wrapper script anyway if we include input methods as dependencies of the GTK+. GTK+ creates an immodules.cache containing the paths to the shared library files of the input methods at $out/lib/gtk-2.0/2.10.0/immodules.cache or $out/lib/gtk-3.0/3.0.0/immodules.cache at build time. GTK+ reads immodules.cache in its lib directory by default.

[lucabrunox]

@taku0 we don't do that for gdkpixbuf. The immodules.cache can be created by a derivation that pulls in all im modules. Then creates the immodules.cache that can be used by wrappers. Wrappers are already there for every gtk app due to gdkpixbuf and other stuff.
This derivation will have a setup-hook that sets GTK2_IM_MODULE and GTK3_IM_MODULE to the immodules.cache.

Then buildInputs = [ immodules ]; and --set GTK_IM_MODULE "$GTK3_IM_MODULE"

[taku0]

@lethalman There are 73 packages wrapping the executables (ag 'GDK_PIXBUF_MODULE_FILE' -G '.*\.nix' pkgs/applications/ pkgs/desktops/ -l | wc -l). On the contrary, there are 267 packages using GTK+ (ag '\bgtk\b' -G '.*\.nix' pkgs/applications/ pkgs/desktops/ -l | wc -l). Wrapping them all would not be a simple task. We also have to ensure new packages wraps them correctly (this would be error prone since the majority of users doesn't use input methods at all). We would at least need some helpers to wrap the executable in some easy way.

[lucabrunox]

@taku0 Non-wrapped gtk apps are not displaying icons properly.
I plan to make a wrapper for glibish stuff. It's just that I'd like to see all patterns first. However, making the change in gtk also makes sense. If one wants to change the modules, one can always wrap the binary. Same goes for gdkpixbuf.
I'm kind of in doubt now. Maybe changing gtk makes sense. After all, if gdkpixbuf changes, gtk changes too already. About IM modules not, but still all gtk apps will have to be recompiled.

[7c6f434c]

Hm. Now we have some uim in NixPkgs.

Should this pull request be closed or changed to be a change from current uim?

[7c6f434c]

@taku0 does current NixPkgs uim version work for you?

[taku0]

@7c6f434c
I'm sorry but I cannot test immediately whether uim works or not with latest NisOS since I'm absent from my home until Oct, and I could not install NixOS on my laptop due to some technical issue. I tested the uim package with a clean virtual machine (build-vm with minimum config) when I wrote the expression.

[Fuuzetsu]

What does this bring on top of #3275 ?

[taku0]

@7c6f434c Now I confirmed that the uim package in current (24 Sep, 0bc83f6) NixPkgs works with GTK+ 2, GTK+ 3, and Qt 4.
I did build-vm with the following configuration.nix

{ config, pkgs, ... }:

{
  imports =
    [
      /etc/nixos/hardware-configuration.nix
    ];

  nixpkgs.config.allowUnfree = true;

  users.extraUsers.taku0 = {
    createHome = true;
    home = "/home/taku0";
    description = "taku0";
    extraGroups = [ "wheel" ];
    isSystemUser = false;
    useDefaultShell = true;
    password = "a";
  };

  i18n = {
    defaultLocale = "ja_JP.UTF-8";
  };

  services.openssh.enable = true;

  services.xserver.enable = true;
  services.xserver.layout = "jp";
  services.xserver.xkbOptions = "";

  services.xserver.desktopManager.xfce.enable = true;

  time.timeZone = "Asia/Tokyo";
  fonts.enableCoreFonts = true;

  uim.enable = true;
}

Steps:

1. Open uim-pref-gtk, uim-pref-gtk3, or uim-pref-qt4.
2. Switch to SKK 辞書 (SKK dictionaries) tab.
3. Focus some input field.
4. Press Shift+Space.
5. Input some text into input field.

[7c6f434c]

@7c6f434c Now I confirmed that the uim package in current (24 Sep, 0bc83f6) NixPkgs works with GTK+ 2, GTK+ 3, and Qt 4.
I did build-vm with the following configuration.nix

Should this pull request be closed as obsolete?

[taku0]

@7c6f434c Yes. A new issue should be opened if needed.