IBus and different GTK versions

IBus and different GTK versions

[Ricardo Wurmus]

Hi Guix,

I’m having some problems using IBus as an input method for all
applications on GuixSD.  Usually, it is enough to specify the following
variables:

    export GTK_IM_MODULE=ibus
    export XMODIFIERS=@im=ibus
    export QT_IM_MODULE=ibus

    export IBUS_COMPONENT_PATH="$HOME/.guix-profile/share/ibus/component"

The last variable is actually suggested by Guix via the search paths
feature (specified on the “ibus” package), while the other three are
suggested when running “ibus-setup”.

Even when these environment variables are set, IBus won’t work right
away.  After installation there is one more issue which can be solved
easily.  IBus uses dconf to store its settings, so changing the settings
with “ibus-setup” requires the dconf-service to be running (I’m planning
to write a dmd service for this):

    $(guix build dconf)/libexec/dconf-service &
    ibus-setup

Okay, now we can actually select input methods and our changes will be
kept.  I installed the “ibus-libpinyin” package for inputting Chinese
characters via pinyin, and selected it from the menu in “ibus-setup”.

Unfortunately, things still don’t work, because the GTK_IM_MODULE “ibus”
cannot be found.  GTK does not know where to look for it.  It looks up
input method modules in a file called “immodules.cache”, which is
generated with “gtk-query-immodules-3.0” for GTK3 and
“gtk-query-immodules-2.0” for GTK2.

Our GTK packages come with “immodules.cache” files at

    $out/lib/gtk-3.0/3.0.0/immodules.cache

and

    $out/lib/gtk-2.0/2.10.0/immodules.cache

for the two different versions of GTK.  Of course, neither of these
files contain a reference to the IBus input module, which is located at

    $out/lib/gtk-3.0/3.0.0/immodules/im-ibus.so
    $out/lib/gtk-2.0/2.10.0/immodules/im-ibus.so

in the output of the “ibus” package.  I can generate an entry for the
immodules.cache file with

    gtk-query-immodules-3.0 ~/.guix-profile/lib/gtk-3.0/3.0.0/immodules/im-ibus.so

and append this to a copy of the GTK immodules.cache file.  To make GTK
use it I need to point to it with the GTK_IM_MODULE_FILE variable.

However, it is not advisable to mix input method modules for different
versions of GTK.  When I did the above and listed both the ‘im-ibus.so’
for GTK2 and GTK3 in the immodules.cache file and opened the graphical
file dialogue in Emacs (which uses GTK3), Emacs would crash with a
segfault if the GTK2 input method module for IBus was listed first.  I
get a similar problem when the GTK3 module is listed first and I try to
run any of the XFCE tools, e.g. ‘xfce4-keyboard-settings’, which all use
GTK2.  They all fail to start when the GTK3 module is listed first.

This means that we cannot just use one cache file and we cannot let
users set GTK_IM_MODULE_FILE for the whole session.  In fact, the GTK
documentation warns that this variable should not be used session-wide.

It seems that GTK3 only looks for
‘$libdir/gtk-3.0/3.0.0/immodules.cache’ and GTK2 only looks for
‘$libdir/gtk-2.0/2.10.0/immodules.cache’ by default, where ‘$libdir’ is
‘$out/lib’ of the GTK package.  (According to
https://developer.gnome.org/gtk3/stable/gtk-running.html)

To make IBus work we need to find a way to make the different major
versions of GTK respect different ‘immodules.cache’ files that are *not*
located in their ‘$libdir’.  In that case we could generate a fresh
‘immodules.cache’ file for each major GTK version when building a
profile.  Unfortunately, I haven’t been able to find any documented
means to achieve this.  It might require patching the GTKs to check an
additional path or environment variable.

If this was the only way to achieve this behaviour I would suggest to
alter the GTKs to respect two variables in addition to the flawed and
dangerous ‘GTK_IM_MODULE_FILE’:

    ‘GTK2_IM_MODULE_FILE’ for GTK2
    ‘GTK3_IM_MODULE_FILE’ for GTK3

Right now, the only way to make IBus work for all GTK applications (no
matter the version) is to edit the ‘immodules.cache’ files in the GTK
packages’ output directory so that each contains a reference to the
correct IBus input method module for the particular GTK version.  This
involves changing stuff in ‘/gnu/store’ and I’m just not comfortable
doing this after each update.

What do you think would be the best approach here?

~~ Ricardo

Re: IBus and different GTK versions

[宋文武]

Ricardo Wurmus <rekado@elephly.net> writes:

> [...]
>
> It seems that GTK3 only looks for
> ‘$libdir/gtk-3.0/3.0.0/immodules.cache’ and GTK2 only looks for
> ‘$libdir/gtk-2.0/2.10.0/immodules.cache’ by default, where ‘$libdir’ is
> ‘$out/lib’ of the GTK package.  (According to
> https://developer.gnome.org/gtk3/stable/gtk-running.html)
>
> To make IBus work we need to find a way to make the different major
> versions of GTK respect different ‘immodules.cache’ files that are *not*
> located in their ‘$libdir’.  In that case we could generate a fresh
> ‘immodules.cache’ file for each major GTK version when building a
> profile.  Unfortunately, I haven’t been able to find any documented
> means to achieve this.  It might require patching the GTKs to check an
> additional path or environment variable.
>
We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
'immodules.cache' files in a profile hook.  It will work for both gtk2
and gtk3 applications.

Re: IBus and different GTK versions

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> [...]
>>
>> It seems that GTK3 only looks for
>> ‘$libdir/gtk-3.0/3.0.0/immodules.cache’ and GTK2 only looks for
>> ‘$libdir/gtk-2.0/2.10.0/immodules.cache’ by default, where ‘$libdir’ is
>> ‘$out/lib’ of the GTK package.  (According to
>> https://developer.gnome.org/gtk3/stable/gtk-running.html)
>>
>> To make IBus work we need to find a way to make the different major
>> versions of GTK respect different ‘immodules.cache’ files that are *not*
>> located in their ‘$libdir’.  In that case we could generate a fresh
>> ‘immodules.cache’ file for each major GTK version when building a
>> profile.  Unfortunately, I haven’t been able to find any documented
>> means to achieve this.  It might require patching the GTKs to check an
>> additional path or environment variable.
>>
> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
> 'immodules.cache' files in a profile hook.  It will work for both gtk2
> and gtk3 applications.

What other things does ‘GTK_EXE_PREFIX’ affect?

The plan you suggest sounds good to me, my only concern is whether
‘GTK_EXE_PREFIX’ is too broad for our purposes.

Thanks,
Ludo’.

Re: IBus and different GTK versions

[Ricardo Wurmus]

宋文武 <iyzsong@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> [...]
>>
>> It seems that GTK3 only looks for
>> ‘$libdir/gtk-3.0/3.0.0/immodules.cache’ and GTK2 only looks for
>> ‘$libdir/gtk-2.0/2.10.0/immodules.cache’ by default, where ‘$libdir’ is
>> ‘$out/lib’ of the GTK package.  (According to
>> https://developer.gnome.org/gtk3/stable/gtk-running.html)
>>
>> To make IBus work we need to find a way to make the different major
>> versions of GTK respect different ‘immodules.cache’ files that are *not*
>> located in their ‘$libdir’.  In that case we could generate a fresh
>> ‘immodules.cache’ file for each major GTK version when building a
>> profile.  Unfortunately, I haven’t been able to find any documented
>> means to achieve this.  It might require patching the GTKs to check an
>> additional path or environment variable.
>>
> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
> 'immodules.cache' files in a profile hook.  It will work for both gtk2
> and gtk3 applications.

Does this mean that GTK needs to be installed in the user’s profile for
this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
a list of paths to look for libraries.

~~ Ricardo

Re: IBus and different GTK versions

[宋文武]

2015-09-14 16:28 GMT+08:00, Ricardo Wurmus <rekado@elephly.net>:
>
> 宋文武 <iyzsong@gmail.com> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> [...]
>>>
>>> It seems that GTK3 only looks for
>>> ‘$libdir/gtk-3.0/3.0.0/immodules.cache’ and GTK2 only looks for
>>> ‘$libdir/gtk-2.0/2.10.0/immodules.cache’ by default, where ‘$libdir’ is
>>> ‘$out/lib’ of the GTK package.  (According to
>>> https://developer.gnome.org/gtk3/stable/gtk-running.html)
>>>
>>> To make IBus work we need to find a way to make the different major
>>> versions of GTK respect different ‘immodules.cache’ files that are *not*
>>> located in their ‘$libdir’.  In that case we could generate a fresh
>>> ‘immodules.cache’ file for each major GTK version when building a
>>> profile.  Unfortunately, I haven’t been able to find any documented
>>> means to achieve this.  It might require patching the GTKs to check an
>>> additional path or environment variable.
>>>
>> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
>> 'immodules.cache' files in a profile hook.  It will work for both gtk2
>> and gtk3 applications.
>
> Does this mean that GTK needs to be installed in the user’s profile for
> this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
> ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
> a list of paths to look for libraries.
Yes, this require install GTK+ into user's profile.
Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
the only way to set the GTK+ 2 theme.

Re: IBus and different GTK versions

[Ricardo Wurmus]

宋文武 <iyzsong@gmail.com> writes:

>>> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
>>> 'immodules.cache' files in a profile hook.  It will work for both gtk2
>>> and gtk3 applications.

>> Does this mean that GTK needs to be installed in the user’s profile for
>> this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
>> ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
>> a list of paths to look for libraries.

> Yes, this require install GTK+ into user's profile.
> Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
> the only way to set the GTK+ 2 theme.

Isn’t this a little too high a price to pay?  One can only install one
(major) version of GTK+ into a profile, so when we begin propagating the
GTK inputs users will run into conflicts.

I would really like to avoid propagating GTK+ (although it may be a bad
idea to have software depend on different minor versions of GTK+).  It
would be very nice if only additional modules—such as explicitly
installed themes and input method modules—would have to be installed to
the profile.  Those who do not need themes or input methods would not
need to be bothered with this at all.

~~ Ricardo

Re: IBus and different GTK versions

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> 宋文武 <iyzsong@gmail.com> writes:
>
>>>> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
>>>> 'immodules.cache' files in a profile hook.  It will work for both gtk2
>>>> and gtk3 applications.
>
>>> Does this mean that GTK needs to be installed in the user’s profile for
>>> this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
>>> ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
>>> a list of paths to look for libraries.
>
>> Yes, this require install GTK+ into user's profile.
>> Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
>> the only way to set the GTK+ 2 theme.
>
> Isn’t this a little too high a price to pay?  One can only install one
> (major) version of GTK+ into a profile, so when we begin propagating the
> GTK inputs users will run into conflicts.
>
> I would really like to avoid propagating GTK+ (although it may be a bad
> idea to have software depend on different minor versions of GTK+).  It
> would be very nice if only additional modules—such as explicitly
> installed themes and input method modules—would have to be installed to
> the profile.  Those who do not need themes or input methods would not
> need to be bothered with this at all.

I guess the question is: what would be the uglier fix?  Do we prefer to
force users to have GTK+ installed in their profiles, or are we okay
with patching the GTK+ sources such that additional environment
variables would be respected, allowing users to specify different
module directories for version 2 and version 3?

~~ Ricardo

Re: IBus and different GTK versions

[Ricardo Wurmus]

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


Ricardo Wurmus <rekado@elephly.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> 宋文武 <iyzsong@gmail.com> writes:
>>
>>>>> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
>>>>> 'immodules.cache' files in a profile hook.  It will work for both gtk2
>>>>> and gtk3 applications.
>>
>>>> Does this mean that GTK needs to be installed in the user’s profile for
>>>> this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
>>>> ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
>>>> a list of paths to look for libraries.
>>
>>> Yes, this require install GTK+ into user's profile.
>>> Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
>>> the only way to set the GTK+ 2 theme.
>>
>> Isn’t this a little too high a price to pay?  One can only install one
>> (major) version of GTK+ into a profile, so when we begin propagating the
>> GTK inputs users will run into conflicts.
>>
>> I would really like to avoid propagating GTK+ (although it may be a bad
>> idea to have software depend on different minor versions of GTK+).  It
>> would be very nice if only additional modules—such as explicitly
>> installed themes and input method modules—would have to be installed to
>> the profile.  Those who do not need themes or input methods would not
>> need to be bothered with this at all.
>
> I guess the question is: what would be the uglier fix?  Do we prefer to
> force users to have GTK+ installed in their profiles, or are we okay
> with patching the GTK+ sources such that additional environment
> variables would be respected, allowing users to specify different
> module directories for version 2 and version 3?

Looking at the GTK sources it occurred to me that there may be yet
another way we could fix this.  GTK3 no longer searches for modules in
~/.gtk-3.0 but GTK2 still looks in ~/.gtk-2.0 by default.  Symlinking
‘~/.guix-profile/lib/gtk-2.0’ to ‘~/.gtk-2.0’ might be sufficient for
GTK2 applications.

For GTK3 we could use the attached (untested) patch, which makes GTK3
look for additional modules in the path specified by the optional
environment variable “GTK3_PATH”.  This way we could point “GTK3_PATH”
at ‘~/.guix-profile/lib/gtk-3.0’, ensuring that only GTK3 applications
load the GTK3 modules and GTK2 don’t crash.

If we wanted symmetry we could patch GTK2 in a similar manner, making it
respect a “GTK2_PATH” variable instead.

What do you think?

~~ Ricardo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gtk3-respect-GTK3_PATH.patch --]
[-- Type: text/x-patch, Size: 1335 bytes --]

This patch makes GTK+ look for additional modules in a list of directories
specified by the environment variable "GTK3_PATH".  This can be used instead
of "GTK_PATH" to make GTK+ find modules that are incompatible with other major
versions of GTK+.

--- a/gtk/gtkmodules.c	2015-09-20 20:09:05.060590217 +0200
+++ b/gtk/gtkmodules.c	2015-09-20 20:10:33.423124833 +0200
@@ -52,6 +52,7 @@
 get_module_path (void)
 {
   const gchar *module_path_env;
+  const gchar *module_gtk3_path_env;
   const gchar *exe_prefix;
   gchar *module_path;
   gchar *default_dir;
@@ -61,6 +62,7 @@
     return result;
 
   module_path_env = g_getenv ("GTK_PATH");
+  module_gtk3_path_env = g_getenv ("GTK3_PATH");
   exe_prefix = g_getenv ("GTK_EXE_PREFIX");
 
   if (exe_prefix)
@@ -68,7 +70,13 @@
   else
     default_dir = g_build_filename (_gtk_get_libdir (), "gtk-3.0", NULL);
 
-  if (module_path_env)
+  if (module_gtk3_path_env && module_path_env)
+    module_path = g_build_path (G_SEARCHPATH_SEPARATOR_S,
+				module_gtk3_path_env, module_path_env, default_dir, NULL);
+  else if (module_gtk3_path_env)
+    module_path = g_build_path (G_SEARCHPATH_SEPARATOR_S,
+				module_gtk3_path_env, default_dir, NULL);
+  else if (module_path_env)
     module_path = g_build_path (G_SEARCHPATH_SEPARATOR_S,
 				module_path_env, default_dir, NULL);
   else

Re: IBus and different GTK versions

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> 宋文武 <iyzsong@gmail.com> writes:
>>>
>>>>>> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
>>>>>> 'immodules.cache' files in a profile hook.  It will work for both gtk2
>>>>>> and gtk3 applications.
>>>
>>>>> Does this mean that GTK needs to be installed in the user’s profile for
>>>>> this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
>>>>> ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
>>>>> a list of paths to look for libraries.
>>>
>>>> Yes, this require install GTK+ into user's profile.
>>>> Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
>>>> the only way to set the GTK+ 2 theme.
>>>
>>> Isn’t this a little too high a price to pay?  One can only install one
>>> (major) version of GTK+ into a profile, so when we begin propagating the
>>> GTK inputs users will run into conflicts.
>>>
>>> I would really like to avoid propagating GTK+ (although it may be a bad
>>> idea to have software depend on different minor versions of GTK+).  It
>>> would be very nice if only additional modules—such as explicitly
>>> installed themes and input method modules—would have to be installed to
>>> the profile.  Those who do not need themes or input methods would not
>>> need to be bothered with this at all.
>>
>> I guess the question is: what would be the uglier fix?  Do we prefer to
>> force users to have GTK+ installed in their profiles, or are we okay
>> with patching the GTK+ sources such that additional environment
>> variables would be respected, allowing users to specify different
>> module directories for version 2 and version 3?

It would not be OK to force users to have GTK+ in their profile.

> Looking at the GTK sources it occurred to me that there may be yet
> another way we could fix this.  GTK3 no longer searches for modules in
> ~/.gtk-3.0 but GTK2 still looks in ~/.gtk-2.0 by default.  Symlinking
> ‘~/.guix-profile/lib/gtk-2.0’ to ‘~/.gtk-2.0’ might be sufficient for
> GTK2 applications.
>
> For GTK3 we could use the attached (untested) patch, which makes GTK3
> look for additional modules in the path specified by the optional
> environment variable “GTK3_PATH”.  This way we could point “GTK3_PATH”
> at ‘~/.guix-profile/lib/gtk-3.0’, ensuring that only GTK3 applications
> load the GTK3 modules and GTK2 don’t crash.

Sounds good.  We should discuss it with upstream, but IMO this patch is
acceptable regardless of what upstream thinks (I’m guessing upstream
targets mainly FHS, where the environment variable is typically
unnecessary in the first place.)

> If we wanted symmetry we could patch GTK2 in a similar manner, making it
> respect a “GTK2_PATH” variable instead.

Yes, that would be best.

Thanks!

Ludo’.