[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trying to fix IBus
From: |
Chris Marusich |
Subject: |
Re: Trying to fix IBus |
Date: |
Fri, 12 Aug 2016 09:34:19 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Ricardo Wurmus <address@hidden> writes:
> Ricardo Wurmus <address@hidden> writes:
>
>> Chris Marusich <address@hidden> 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
signature.asc
Description: PGP signature