Trying to fix IBus

Trying to fix IBus

[Ricardo Wurmus]

Hi Guix,

IBus is still broken.  That’s primarily because we don’t generate an
input method modules cache file that GTK+ looks for.  The cache file for
GTK3 can be generated with

    gtk-query-immodules-3.0 /path/to/profile

Then we point the environment variable GTK_IM_MODULE_FILE to the file.
I tried this, rebooted, and noticed that now any GTK2 application
crashes.  That’s because GTK_IM_MODULE_FILE is used by both major GTK
versions, but the input method modules are not compatible with both
versions.

NixOS encountered the same problem:

    https://github.com/NixOS/nixpkgs/pull/14568

I don’t like their solution to set a variable NIX_PROFILES and let GTK
look for immodule files in each of the directories.  Instead, I think we
should patch both GTK versions to respect GUIX_GTK2_IM_MODULE_FILE and
GUIX_GTK3_IM_MODULE_FILE, and generate the immodule cache files in a
profile hook.

We did something similar before with GUIX_GTK2_PATH and GUIX_GTK3_PATH.

Upstream doesn’t want to accept patches like this because they are
moving away from dynamically switchable input method modules.  Instead
they will just support a single input method system per platform.  This
means that ultimately we will be able to drop these patches.

What do you think?  Is this acceptable/reasonable?

~~ Ricardo

Re: Trying to fix IBus

[Alex Griffin]

On Wed, Aug 10, 2016, at 04:09 PM, Ricardo Wurmus wrote:
> What do you think?  Is this acceptable/reasonable?

It seems to me like it's probably fine, for whatever that's worth, and
also cleaner than the NIX_PROFILES solution. How will this work on
foreign distros, though?
-- 
Alex Griffin

Re: Trying to fix IBus

[Ricardo Wurmus]

Alex Griffin <a@ajgrf.com> writes:

> On Wed, Aug 10, 2016, at 04:09 PM, Ricardo Wurmus wrote:
>> What do you think?  Is this acceptable/reasonable?
>
> It seems to me like it's probably fine, for whatever that's worth, and
> also cleaner than the NIX_PROFILES solution. How will this work on
> foreign distros, though?

On foreign distros you would have to use IBus from Guix with GTK from
Guix.  This means that installing IBus from Guix and expecting it to
work with the foreign distro’s applications won’t work.  Likewise you
cannot use the distro’s IBus and use it in applications installed via
Guix.

That’s a general problem — we already experience this with R or Python
(mixing modules installed via different means causes crashes).

~~ Ricardo

Re: Trying to fix IBus

[Chris Marusich]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> NixOS encountered the same problem:
>
>     https://github.com/NixOS/nixpkgs/pull/14568
>
> I don’t like their solution to set a variable NIX_PROFILES and let GTK
> look for immodule files in each of the directories.

Why don't you like their solution?  Why do you believe that your
proposed solution is better than their solution?  We should make sure to
choose the best solution available, and right now I'm not sure which one
is better.

> Instead, I think we should patch both GTK versions to respect
> GUIX_GTK2_IM_MODULE_FILE and GUIX_GTK3_IM_MODULE_FILE, and generate
> the immodule cache files in a profile hook.
>
> We did something similar before with GUIX_GTK2_PATH and GUIX_GTK3_PATH.

I believe you are referring to this thread:

https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html

Did that patch actually get committed?  If so, why didn't it solve the
problem?  I've read all the relevant discussions I could find [1], and
it isn't clear to me why we need to do what you're suggesting ("patch
both GTK versions to respect GUIX_GTK2_IM_MODULE_FILE and
GUIX_GTK3_IM_MODULE_FILE, and generate the immodule cache files in a
profile hook") if we've already committed the patch presented in the
thread above.

> What do you think?  Is this acceptable/reasonable?

Because upstream has made it clear that they won't accept a patch like
this, I think it'd be great to patch it ourselves and fix it.  I think
it would be nice to have a solution that is similar to what NixOS does,
but if your patch is really better than NixOS' solution, I would love to
see it committed.

Ricardo Wurmus <rekado@elephly.net> writes:

> Alex Griffin <a@ajgrf.com> writes:
>
>> On Wed, Aug 10, 2016, at 04:09 PM, Ricardo Wurmus wrote:
>>> What do you think?  Is this acceptable/reasonable?
>>
>> It seems to me like it's probably fine, for whatever that's worth, and
>> also cleaner than the NIX_PROFILES solution. How will this work on
>> foreign distros, though?
>
> On foreign distros you would have to use IBus from Guix with GTK from
> Guix.  This means that installing IBus from Guix and expecting it to
> work with the foreign distro’s applications won’t work.  Likewise you
> cannot use the distro’s IBus and use it in applications installed via
> Guix.
>
> That’s a general problem — we already experience this with R or Python
> (mixing modules installed via different means causes crashes).

As unpleasant as that would be, it would still be better than the
current situation, in which IBus doesn't work for all installed
applications due to the GTK+ major version incompatibility.

Footnotes: 
[1] All the threads here:

* GuixSD discussion:
  https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00306.html

* GuixSD solution (?):
  https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html

* More GuixSD discussion (I wasn't aware of the other threads at the
  time):https://lists.gnu.org/archive/html/help-guix/2016-04/msg00006.html

* NixOS solution: https://github.com/NixOS/nixpkgs/pull/14568

* NixOS discussion: https://github.com/NixOS/nixpkgs/pull/14417

* Upstream response to NixOS patch:
  https://bugzilla.gnome.org/show_bug.cgi?id=764551

-- 
Chris

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

Re: Trying to fix IBus

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> NixOS encountered the same problem:
>>
>>     https://github.com/NixOS/nixpkgs/pull/14568
>>
>> I don’t like their solution to set a variable NIX_PROFILES and let GTK
>> look for immodule files in each of the directories.
>
> Why don't you like their solution?  Why do you believe that your
> proposed solution is better than their solution?  We should make sure to
> choose the best solution available, and right now I'm not sure which one
> is better.

I find it very inelegant to ask users to specify a list of directories
containing profiles.  A mechanism like that also seems like a hack to
me, and I’m afraid that we would begin to rely more and more on this to
“solve” other problems.

Splitting a variable that GTK is already using anyway into two different
versions just seems a lot cleaner to me.  The variable won’t even need
to be exposed to most users; we could set it automatically when
generating profiles.

Eventually this will disappear once the GTK devs retire support for
separate input method modules (I guess this would make IBus a hard
dependency on GNU systems).  At that point we can easily drop our
patches and the profile hook; a generic GUIX_PROFILES variable, on the
other hand, would be more difficult to deprecate if it becomes more
popular (as it has a much broader scope).

>> Instead, I think we should patch both GTK versions to respect
>> GUIX_GTK2_IM_MODULE_FILE and GUIX_GTK3_IM_MODULE_FILE, and generate
>> the immodule cache files in a profile hook.
>>
>> We did something similar before with GUIX_GTK2_PATH and GUIX_GTK3_PATH.
>
> I believe you are referring to this thread:
>
> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html
>
> Did that patch actually get committed?  If so, why didn't it solve the
> problem?  I've read all the relevant discussions I could find [1], and
> it isn't clear to me why we need to do what you're suggesting ("patch
> both GTK versions to respect GUIX_GTK2_IM_MODULE_FILE and
> GUIX_GTK3_IM_MODULE_FILE, and generate the immodule cache files in a
> profile hook") if we've already committed the patch presented in the
> thread above.

Yes, that patch got committed and it actually solved a problem.  It is a
different problem, though.  GTK really assumes modules to be in one
place, which means that with immutable directories we have no other way
to make things work.

~~ Ricardo

Re: Trying to fix IBus

[Chris Marusich]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> NixOS encountered the same problem:
>>>
>>>     https://github.com/NixOS/nixpkgs/pull/14568
>>>
>>> I don’t like their solution to set a variable NIX_PROFILES and let GTK
>>> look for immodule files in each of the directories.
>>
>> Why don't you like their solution?  Why do you believe that your
>> proposed solution is better than their solution?  We should make sure to
>> choose the best solution available, and right now I'm not sure which one
>> is better.
>
> I find it very inelegant to ask users to specify a list of directories
> containing profiles.  A mechanism like that also seems like a hack to
> me, and I’m afraid that we would begin to rely more and more on this to
> “solve” other problems.
>
> Splitting a variable that GTK is already using anyway into two different
> versions just seems a lot cleaner to me.  The variable won’t even need
> to be exposed to most users; we could set it automatically when
> generating profiles.
>
> Eventually this will disappear once the GTK devs retire support for
> separate input method modules (I guess this would make IBus a hard
> dependency on GNU systems).  At that point we can easily drop our
> patches and the profile hook; a generic GUIX_PROFILES variable, on the
> other hand, would be more difficult to deprecate if it becomes more
> popular (as it has a much broader scope).

That makes sense.  I think these are good reasons to favor your solution
instead of the NixOS solution.  I think your plan is good.

>>> Instead, I think we should patch both GTK versions to respect
>>> GUIX_GTK2_IM_MODULE_FILE and GUIX_GTK3_IM_MODULE_FILE, and generate
>>> the immodule cache files in a profile hook.
>>>
>>> We did something similar before with GUIX_GTK2_PATH and GUIX_GTK3_PATH.
>>
>> I believe you are referring to this thread:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html
>>
>> Did that patch actually get committed?  If so, why didn't it solve the
>> problem?  I've read all the relevant discussions I could find [1], and
>> it isn't clear to me why we need to do what you're suggesting ("patch
>> both GTK versions to respect GUIX_GTK2_IM_MODULE_FILE and
>> GUIX_GTK3_IM_MODULE_FILE, and generate the immodule cache files in a
>> profile hook") if we've already committed the patch presented in the
>> thread above.
>
> Yes, that patch got committed and it actually solved a problem.  It is a
> different problem, though.  GTK really assumes modules to be in one
> place, which means that with immutable directories we have no other way
> to make things work.

I see.  I guess I just wasn't familiar with the other issue.  Thank you
for explaining.

One last thing: it seems that the NixOS devs' choice of solution was
influenced by a desire not to require users to rebuild programs that
were previously installed in their profiles [1].  They almost chose a
solution like the one you are proposing, but they changed their minds to
avoid requiring users to rebuild existing programs in their profiles.
GuixSD is still Beta, so I don't think that's an issue for us at all.

[1] See abbradar's comment on April 8th, 2016:

https://github.com/NixOS/nixpkgs/pull/14417#issuecomment-207362530

"This patch would break all such software that uses old (unpatched)
GTK+3."

This appears to be the primary reason why they chose to patch GTK+2 and
GTK+3 to search NIX_PROFILES for an immodules.cache file instead of
patching it to use separate environment variables for GTK+2 and GTK+3.

-- 
Chris

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

Re: Trying to fix IBus

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> One last thing: it seems that the NixOS devs' choice of solution was
> influenced by a desire not to require users to rebuild programs that
> were previously installed in their profiles [1].  They almost chose a
> solution like the one you are proposing, but they changed their minds to
> avoid requiring users to rebuild existing programs in their profiles.
> GuixSD is still Beta, so I don't think that's an issue for us at all.
>
> [1] See abbradar's comment on April 8th, 2016:
>
> https://github.com/NixOS/nixpkgs/pull/14417#issuecomment-207362530
>
> "This patch would break all such software that uses old (unpatched)
> GTK+3."
>
> This appears to be the primary reason why they chose to patch GTK+2 and
> GTK+3 to search NIX_PROFILES for an immodules.cache file instead of
> patching it to use separate environment variables for GTK+2 and GTK+3.

Right, I saw that too, but I really don’t think it applies to us.  I’m
not familiar with the state of IBus in NixOS before the change to
NIX_PROFILES, but I don’t see how this would break existing software.

The reason for crashes is that GTK2 software is made to load GTK3 input
method modules (and vice versa).  We don’t set any variables right now
that could have this effect.  When adding the “GUIX_GTK{2,3}_*”
variables, software built with the unpatched GTK would just ignore input
methods.

If I understand correctly, NixOS installs (or used to install) IBus
system-wide and has system-wide caches (at /etc/…/immodules.cache).  Our
caches would exist on a per-profile base.

If you are more familiar with this problem in NixOS and you think I’m
overlooking something I’d be happy if you could show me what I’m
missing, but I really think that we wouldn’t be bitten by a problem like
this.  In our case software using the pre-patch GTK versions would
behave just like they do now: simply without IBus support.

~~ Ricardo

Re: Trying to fix IBus

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> One last thing: it seems that the NixOS devs' choice of solution was
>> influenced by a desire not to require users to rebuild programs that
>> were previously installed in their profiles [1].  They almost chose a
>> solution like the one you are proposing, but they changed their minds to
>> avoid requiring users to rebuild existing programs in their profiles.
>> GuixSD is still Beta, so I don't think that's an issue for us at all.
>>
>> [1] See abbradar's comment on April 8th, 2016:
>>
>> https://github.com/NixOS/nixpkgs/pull/14417#issuecomment-207362530
>>
>> "This patch would break all such software that uses old (unpatched)
>> GTK+3."
>>
>> This appears to be the primary reason why they chose to patch GTK+2 and
>> GTK+3 to search NIX_PROFILES for an immodules.cache file instead of
>> patching it to use separate environment variables for GTK+2 and GTK+3.
>
> Right, I saw that too, but I really don’t think it applies to us.  I’m
> not familiar with the state of IBus in NixOS before the change to
> NIX_PROFILES, but I don’t see how this would break existing software.
>
> The reason for crashes is that GTK2 software is made to load GTK3 input
> method modules (and vice versa).  We don’t set any variables right now
> that could have this effect.  When adding the “GUIX_GTK{2,3}_*”
> variables, software built with the unpatched GTK would just ignore input
> methods.
>
> If I understand correctly, NixOS installs (or used to install) IBus
> system-wide and has system-wide caches (at /etc/…/immodules.cache).  Our
> caches would exist on a per-profile base.
>
> If you are more familiar with this problem in NixOS and you think I’m
> overlooking something I’d be happy if you could show me what I’m
> missing, but I really think that we wouldn’t be bitten by a problem like
> this.  In our case software using the pre-patch GTK versions would
> behave just like they do now: simply without IBus support.


One more thing: we could also preempt the decision of GTK upstream and
hardcode IBus as the only possible input method system (as has been
suggested on the NixOS discussion), but I think that we should rather
avoid patching things more than absolutely necessary.

(Some people prefer fcitx over IBus; I don’t want to force them to
migrate to IBus when there’s a simple alternative.)

~~ Ricardo

Re: Trying to fix IBus

[Chris Marusich]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Chris Marusich <cmmarusich@gmail.com> writes:
>>
>>> One last thing: it seems that the NixOS devs' choice of solution was
>>> influenced by a desire not to require users to rebuild programs that
>>> were previously installed in their profiles [1].  They almost chose a
>>> solution like the one you are proposing, but they changed their minds to
>>> avoid requiring users to rebuild existing programs in their profiles.
>>> GuixSD is still Beta, so I don't think that's an issue for us at all.
>>>
>>> [1] See abbradar's comment on April 8th, 2016:
>>>
>>> https://github.com/NixOS/nixpkgs/pull/14417#issuecomment-207362530
>>>
>>> "This patch would break all such software that uses old (unpatched)
>>> GTK+3."
>>>
>>> This appears to be the primary reason why they chose to patch GTK+2 and
>>> GTK+3 to search NIX_PROFILES for an immodules.cache file instead of
>>> patching it to use separate environment variables for GTK+2 and GTK+3.
>>
>> Right, I saw that too, but I really don’t think it applies to us.  I’m
>> not familiar with the state of IBus in NixOS before the change to
>> NIX_PROFILES, but I don’t see how this would break existing software.
>>
>> The reason for crashes is that GTK2 software is made to load GTK3 input
>> method modules (and vice versa).  We don’t set any variables right now
>> that could have this effect.  When adding the “GUIX_GTK{2,3}_*”
>> variables, software built with the unpatched GTK would just ignore input
>> methods.
>>
>> If I understand correctly, NixOS installs (or used to install) IBus
>> system-wide and has system-wide caches (at /etc/…/immodules.cache).  Our
>> caches would exist on a per-profile base.
>>
>> If you are more familiar with this problem in NixOS and you think I’m
>> overlooking something I’d be happy if you could show me what I’m
>> missing, but I really think that we wouldn’t be bitten by a problem like
>> this.  In our case software using the pre-patch GTK versions would
>> behave just like they do now: simply without IBus support.

I might be mistaken, but the patch which the NixOS devs originally
considered in pull request 14417 removed code that appears to
automatically overwrite $out/lib/gtk-3.0/3.0.0/immodules.cache in the
store every time someone installs something that depends on GTK+3:

https://github.com/NixOS/nixpkgs/pull/14417/files#diff-9be1673bb42206c648aec0c894c231deL54

It's possible that is the reason why astsmtl observed that pasystray
worked before the patch, but not after.  I'm not exactly sure.

In any case, I agree we probably don't have to worry about it.

> One more thing: we could also preempt the decision of GTK upstream and
> hardcode IBus as the only possible input method system (as has been
> suggested on the NixOS discussion), but I think that we should rather
> avoid patching things more than absolutely necessary.
>
> (Some people prefer fcitx over IBus; I don’t want to force them to
> migrate to IBus when there’s a simple alternative.)

I agree.

-- 
Chris

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