guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trying to fix IBus


From: Ricardo Wurmus
Subject: Re: Trying to fix IBus
Date: Thu, 11 Aug 2016 15:17:14 +0200
User-agent: mu4e 0.9.16; emacs 25.1.1

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.


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]