[PATCH 0/2] Fix IBus input methods.

[PATCH 0/2] Fix IBus input methods.

[Ricardo Wurmus]

Hi Guix,

with these patches different versions of GTK+ can be given different input
method module caches.

Currently, the problem with additional GTK input methods (such as IBus) is
that to make them visible you need to generate a cache file and point to it
with GTK_IM_MODULE_FILE.  Since this variable is respected by both major
versions of GTK+ (and the cache file doesn't allow specification of input
method modules for specific versions of GTK+) incompatible input method
modules will be loaded, which results in crashes.

By splitting GTK_IM_MODULE_FILE into GUIX_GTK2_IM_MODULE_FILE and
GUIX_GTK3_IM_MODULE_FILE we can bypass this problem as GTK+ applications will
only load modules compatible with their major version.

I've tested this by generating two cache files for both versions with
"gtk-query-immodules-2.0" and "gtk-query-immodules-3.0" and setting the
variables.  This allows me to use IBus libpinyin in all (tested) GTK
applications.

What doesn't yet work is IBus input methods using the simple engine, such as
Arabic, but this seems unrelated.

~~ Ricardo


Ricardo Wurmus (2):
  gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
  gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.

 gnu/local.mk                                              |  2 ++
 gnu/packages/gtk.scm                                      |  4 +++-
 .../patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch   | 15 +++++++++++++++
 .../patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch   | 15 +++++++++++++++
 4 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch
 create mode 100644 gnu/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch

-- 
2.9.2

[PATCH 1/2] gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.

[Ricardo Wurmus]

* gnu/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch: New file.
* gnu/packages/gtk.scm (gtk+-2)[source]: Add it.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk                                              |  1 +
 gnu/packages/gtk.scm                                      |  1 +
 .../patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch   | 15 +++++++++++++++
 3 files changed, 17 insertions(+)
 create mode 100644 gnu/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index b8c5378..3cb85d1 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -550,6 +550,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/guile-relocatable.patch			\
   %D%/packages/patches/guile-rsvg-pkgconfig.patch		\
   %D%/packages/patches/gtk2-respect-GUIX_GTK2_PATH.patch	\
+  %D%/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch \
   %D%/packages/patches/gtk2-theme-paths.patch			\
   %D%/packages/patches/gtk3-respect-GUIX_GTK3_PATH.patch	\
   %D%/packages/patches/gtkglext-disable-disable-deprecated.patch \
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 8feac11..e1d9cf9 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -563,6 +563,7 @@ is part of the GNOME accessibility project.")
              (base32
               "0l6aqk86aw5w132ygy6hv6nlxvd1h6xg7c85qbm60p6mnv1ww58d"))
             (patches (search-patches "gtk2-respect-GUIX_GTK2_PATH.patch"
+                                     "gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch"
                                      "gtk2-theme-paths.patch"))))
    (build-system gnu-build-system)
    (outputs '("out" "doc"))
diff --git a/gnu/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch b/gnu/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch
new file mode 100644
index 0000000..f399024
--- /dev/null
+++ b/gnu/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch
@@ -0,0 +1,15 @@
+This patch replaces the environment variable "GTK_IM_MODULE" with
+"GUIX_GTK2_IM_MODULE_FILE" to prevent this version of GTK+ from loading input
+method modules for other major versions of GTK+.
+
+--- gtk+-2.24.30/gtk/gtkrc.c	2016-08-21 22:40:22.339660438 +0200
++++ gtk+-2.24.30/gtk/gtkrc.c	2016-08-23 10:11:11.080822710 +0200
+@@ -439,7 +439,7 @@
+ gchar *
+ gtk_rc_get_im_module_file (void)
+ {
+-  const gchar *var = g_getenv ("GTK_IM_MODULE_FILE");
++  const gchar *var = g_getenv ("GUIX_GTK2_IM_MODULE_FILE");
+   gchar *result = NULL;
+ 
+   if (var)
-- 
2.9.2

[PATCH 2/2] gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.

[Ricardo Wurmus]

* gnu/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch: New file.
* gnu/packages/gtk.scm (gtk+)[source]: Add it.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk                                              |  1 +
 gnu/packages/gtk.scm                                      |  3 ++-
 .../patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch   | 15 +++++++++++++++
 3 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 3cb85d1..263b93c 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -553,6 +553,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch \
   %D%/packages/patches/gtk2-theme-paths.patch			\
   %D%/packages/patches/gtk3-respect-GUIX_GTK3_PATH.patch	\
+  %D%/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch \
   %D%/packages/patches/gtkglext-disable-disable-deprecated.patch \
   %D%/packages/patches/hdf5-config-date.patch			\
   %D%/packages/patches/higan-remove-march-native-flag.patch	\
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index e1d9cf9..396ff1f 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -625,7 +625,8 @@ application suites.")
             (sha256
              (base32
               "157nh9gg0p2avw765hrnkvr8lsh2w811397yxgjv6q5j4fzz6d1q"))
-            (patches (search-patches "gtk3-respect-GUIX_GTK3_PATH.patch"))))
+            (patches (search-patches "gtk3-respect-GUIX_GTK3_PATH.patch"
+                                     "gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch"))))
    (propagated-inputs
     `(("at-spi2-atk" ,at-spi2-atk)
       ("atk" ,atk)
diff --git a/gnu/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch b/gnu/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch
new file mode 100644
index 0000000..aa63a54
--- /dev/null
+++ b/gnu/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch
@@ -0,0 +1,15 @@
+This patch replaces the environment variable "GTK_IM_MODULE" with
+"GUIX_GTK3_IM_MODULE_FILE" to prevent this version of GTK+ from loading input
+method modules for other major versions of GTK+.
+
+--- gtk+-3.20.3/gtk/deprecated/gtkrc.c	2016-08-21 22:40:48.168437905 +0200
++++ gtk+-3.20.3/gtk/deprecated/gtkrc.c	2016-08-23 10:12:09.097070097 +0200
+@@ -768,7 +768,7 @@
+ gchar *
+ gtk_rc_get_im_module_file (void)
+ {
+-  const gchar *var = g_getenv ("GTK_IM_MODULE_FILE");
++  const gchar *var = g_getenv ("GUIX_GTK3_IM_MODULE_FILE");
+   gchar *result = NULL;
+ 
+   if (var)
-- 
2.9.2

Re: [PATCH 0/2] Fix IBus input methods.

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> What doesn't yet work is IBus input methods using the simple engine, such as
> Arabic, but this seems unrelated.

That’s been fixed in d37f00b97fc12a677409e13759fe3edc6ffede2c.

IBus had a couple of hard-coded paths and missing
inputs.  Arabic, English Qwerty, English Dvorak, German Qwertz, and
Chinese (via ibus-libpinyin) all work for me now.

Note that “Use system keyboard layout” in the “Advanced” tab of
“ibus-setup” has to be *unchecked* for the simple engine to work right.
With that option checked it would be stuck at English Dvorak, which had
been set via setxkbmap at the start of the session.

~~ Ricardo

Re: [PATCH 0/2] Fix IBus input methods.

[宋文武]

Ricardo Wurmus <rekado@elephly.net> writes:

>   gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
>   gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.

Look good to me!

Re: [PATCH 0/2] Fix IBus input methods.

[Ricardo Wurmus]

宋文武 <iyzsong@member.fsf.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>   gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
>>   gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.
>
> Look good to me!

Thanks!

What do you think: should this be a separate branch (e.g. “gtk-rebuild”)
or should it be pushed to “core-updates”?

~~ Ricardo

Re: [PATCH 0/2] Fix IBus input methods.

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> 宋文武 <iyzsong@member.fsf.org> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>>   gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
>>>   gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.
>>
>> Look good to me!
>
> Thanks!
>
> What do you think: should this be a separate branch (e.g. “gtk-rebuild”)
> or should it be pushed to “core-updates”?

As discussed on IRC, I’ve added a “jobset”:

  https://hydra.gnu.org/jobset/gnu/gtk-im-modules

There seems to be only 1 new failure compared to ‘master’:

  https://hydra.gnu.org/eval/109124?compare=master#tabs-now-fail

Could you take a look?

We’ll have to merge ‘master’ into it and evaluate it again.

Thanks,
Ludo’.

Re: [PATCH 0/2] Fix IBus input methods.

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> 宋文武 <iyzsong@member.fsf.org> writes:
>>
>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>
>>>>   gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
>>>>   gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.
>>>
>>> Look good to me!
>>
>> Thanks!
>>
>> What do you think: should this be a separate branch (e.g. “gtk-rebuild”)
>> or should it be pushed to “core-updates”?
>
> As discussed on IRC, I’ve added a “jobset”:
>
>   https://hydra.gnu.org/jobset/gnu/gtk-im-modules
>
> There seems to be only 1 new failure compared to ‘master’:
>
>   https://hydra.gnu.org/eval/109124?compare=master#tabs-now-fail
>
> Could you take a look?

This looks unrelated to me.  The error is that
“tests/autojump_utils_test.py” cannot be opened in the “check” phase.
That’s expected because the file is actually called
“tests/unit/autojump_utils_test.py” (note the “unit” directory).

I’m convinced my patch to the GTKs couldn’t possibly have caused this.

Here are the relevant parts of the log:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
starting phase `unpack'
[...]
autojump-release-v22.3.4/tests/unit/
autojump-release-v22.3.4/tests/unit/__init__.py
autojump-release-v22.3.4/tests/unit/autojump_match_test.py
autojump-release-v22.3.4/tests/unit/autojump_utils_test.py
[...]
phase `unpack' succeeded after 0.1 seconds
[...]
starting phase `patch-source-shebangs'
[...]
patch-shebang: ./tests/unit/autojump_utils_test.py: changing `/usr/bin/env python' to `/gnu/store/wa1yc835mb7pmmrj45xfgviqr5fbasqq-python-wrapper-3.4.3/bin/python'
patch-shebang: ./uninstall.py: changing `/usr/bin/env python' to `/gnu/store/wa1yc835mb7pmmrj45xfgviqr5fbasqq-python-wrapper-3.4.3/bin/python'
phase `patch-source-shebangs' succeeded after 0.1 seconds
starting phase `patch-generated-file-shebangs'
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `check'
python: can't open file 'tests/autojump_utils_test.py': [Errno 2] No such file or directory
phase `check' failed after 1.8 seconds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> We’ll have to merge ‘master’ into it and evaluate it again.

Can “gtk-im-modules” not be merged into the master branch directly?

~~ Ricardo

Re: [PATCH 0/2] Fix IBus input methods.

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>
>>> 宋文武 <iyzsong@member.fsf.org> writes:
>>>
>>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>>
>>>>>   gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
>>>>>   gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.
>>>>
>>>> Look good to me!
>>>
>>> Thanks!
>>>
>>> What do you think: should this be a separate branch (e.g. “gtk-rebuild”)
>>> or should it be pushed to “core-updates”?
>>
>> As discussed on IRC, I’ve added a “jobset”:
>>
>>   https://hydra.gnu.org/jobset/gnu/gtk-im-modules
>>
>> There seems to be only 1 new failure compared to ‘master’:
>>
>>   https://hydra.gnu.org/eval/109124?compare=master#tabs-now-fail
>>
>> Could you take a look?
>
> This looks unrelated to me.

OK.

>> We’ll have to merge ‘master’ into it and evaluate it again.
>
> Can “gtk-im-modules” not be merged into the master branch directly?

One benefit of having a separate jobset is that we can wait until
everything is built before merging to master.  The problem here is that
this branch was entirely built several days ago, so it might be somewhat
outdated now.

Thus, could you either (1) merge locally into master and make sure no
important binaries are missing (try “guix build emacs -n” or similar),
and if that is the case, you can push; or (2) merge master into
gtk-im-modules and reevaluate the jobset?

Thanks in advance!  :-)

Ludo’.

Re: [PATCH 0/2] Fix IBus input methods.

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>>
>>>> 宋文武 <iyzsong@member.fsf.org> writes:
>>>>
>>>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>>>
>>>>>>   gnu: gtk+-2: Add patch to support GUIX_GTK2_IM_MODULE_FILE.
>>>>>>   gnu: gtk+: Add patch to support GUIX_GTK3_IM_MODULE_FILE.
>>>>>
>>>>> Look good to me!
>>>>
>>>> Thanks!
>>>>
>>>> What do you think: should this be a separate branch (e.g. “gtk-rebuild”)
>>>> or should it be pushed to “core-updates”?
>>>
>>> As discussed on IRC, I’ve added a “jobset”:
>>>
>>>   https://hydra.gnu.org/jobset/gnu/gtk-im-modules
>>>
>>> There seems to be only 1 new failure compared to ‘master’:
>>>
>>>   https://hydra.gnu.org/eval/109124?compare=master#tabs-now-fail
>>>
>>> Could you take a look?
>>
>> This looks unrelated to me.
>
> OK.
>
>>> We’ll have to merge ‘master’ into it and evaluate it again.
>>
>> Can “gtk-im-modules” not be merged into the master branch directly?
>
> One benefit of having a separate jobset is that we can wait until
> everything is built before merging to master.  The problem here is that
> this branch was entirely built several days ago, so it might be somewhat
> outdated now.

I understand.

> Thus, could you either (1) merge locally into master and make sure no
> important binaries are missing (try “guix build emacs -n” or similar),
> and if that is the case, you can push; or (2) merge master into
> gtk-im-modules and reevaluate the jobset?

I tried with “emacs”, “icecat”, “epiphany”, “ardour”, “gnome-desktop”,
“libgnomeui”, and “libxfce4ui” — all of them only report that they would
download substitutes.  None report that anything would need to be built
locally.

So, I’ll go ahead and merge “gtk-im-modules” into “master” and push to
master in a few minutes.

~~ Ricardo

Re: [PATCH 0/2] Fix IBus input methods.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> with these patches different versions of GTK+ can be given different input
> method module caches.
>
> Currently, the problem with additional GTK input methods (such as IBus) is
> that to make them visible you need to generate a cache file and point to it
> with GTK_IM_MODULE_FILE.  Since this variable is respected by both major
> versions of GTK+ (and the cache file doesn't allow specification of input
> method modules for specific versions of GTK+) incompatible input method
> modules will be loaded, which results in crashes.
>
> By splitting GTK_IM_MODULE_FILE into GUIX_GTK2_IM_MODULE_FILE and
> GUIX_GTK3_IM_MODULE_FILE we can bypass this problem as GTK+ applications will
> only load modules compatible with their major version.
>
> I've tested this by generating two cache files for both versions with
> "gtk-query-immodules-2.0" and "gtk-query-immodules-3.0" and setting the
> variables.  This allows me to use IBus libpinyin in all (tested) GTK
> applications.

This is so good.  Thank you for doing it!  I am happy to confirm that
Japanese input via ibus-anthy works like a charm after your changes.
All I had to do was the following:

(1) install ibus, ibus-anthy, and anthy (anthy is probably not strictly
necessary to have in my profile, but it provides a potentially useful
tool for managing user dictionaries, so I want it in my profile),

(2) generate two cache files for both GTK+ versions with
"gtk-query-immodules-2.0" and "gtk-query-immodules-3.0" (it took me a
minute to find the latter program, which was hiding in the "bin" output
of the gtk+@3.20.9 package),

(3) set the environment variables GUIX_GTK2_IM_MODULE_FILE and
GUIX_GTK3_IM_MODULE_FILE to those files (I added export statements to my
~/.bashrc to make it permanent), and

(4) restart xorg-server via "sudo herd restart xorg-server" to ensure
my new environment variables would be seen by all programs I launch.

After that, Japanese input using ibus-anthy just works in GNOME3.  It
works in Icecat, Gedit, GNOME Terminal, and even Emacs (although I
learned recently that Emacs has a great Japanese IME of its own [1]).

Curiously, I did not have to set GTK_IM_MODULE at all.  Even though
GTK_IM_MODULE is not set to anything, Japanese input using ibus-anthy
works.  I guess GTK+ must be automatically finding the right input
method module via some other mechanism.  Whatever - I'm happy for now!

My only concern is that when installing ibus , Guix displays no message
indicating to the user that they will need to go through the above steps
to get their input methods working.  It would also be nice if we could
emit a similar message any time ibus or one of its engines, like
ibus-anthy, is installed/removed/updated, since as you know it is
necessary to regenerate the immodules cache files in that case [2].  Is
there a way to notify the user when installing?  Or, would it be better
to just describe what needs to be done in the manual?

[1] https://lists.gnu.org/archive/html/help-guix/2016-04/msg00052.html
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22707

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH 0/2] Fix IBus input methods.

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> This is so good.  Thank you for doing it!  I am happy to confirm that
> Japanese input via ibus-anthy works like a charm after your changes.
> All I had to do was the following:

I’m glad this works for you!

> (1) install ibus, ibus-anthy, and anthy (anthy is probably not strictly
> necessary to have in my profile, but it provides a potentially useful
> tool for managing user dictionaries, so I want it in my profile),
>
> (2) generate two cache files for both GTK+ versions with
> "gtk-query-immodules-2.0" and "gtk-query-immodules-3.0" (it took me a
> minute to find the latter program, which was hiding in the "bin" output
> of the gtk+@3.20.9 package),

This step shouldn’t be necessary.  The cache files are generated in a
profile hook:

    ~/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache
    ~/.guix-profile/lib/gtk-2.0/2.10.0/immodules-gtk2.cache

You only need to set GUIX_GTK3_IM_MODULE_FILE /
GUIX_GTK2_IM_MODULE_FILE.

> My only concern is that when installing ibus , Guix displays no message
> indicating to the user that they will need to go through the above steps
> to get their input methods working.  It would also be nice if we could
> emit a similar message any time ibus or one of its engines, like
> ibus-anthy, is installed/removed/updated, since as you know it is
> necessary to regenerate the immodules cache files in that case [2].  Is
> there a way to notify the user when installing?  Or, would it be better
> to just describe what needs to be done in the manual?

I’d prefer documenting this in the manual.  Would you like to do this?

(I should also note that the simple XKB input methods (e.g. Arabic) no
longer work via IBus.  They work when switching XKB input methods using
the Xfce Keyboard Layout switcher widget, though.  Something’s broken
there, but I’m not sure what it is.  I got it to work once before.)

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC