Re: Trying to fix IBus

[Chris Marusich <cmmarusich@gmail.com>]

[-- 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 --]