From: Ricardo Wurmus <rekado@elephly.net>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Trying to fix IBus
Date: Thu, 11 Aug 2016 15:17:14 +0200 [thread overview]
Message-ID: <8737mbcun9.fsf@elephly.net> (raw)
In-Reply-To: <874m6rcuun.fsf@elephly.net>
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
next prev parent reply other threads:[~2016-08-11 13:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-10 21:09 Trying to fix IBus Ricardo Wurmus
2016-08-10 22:35 ` Alex Griffin
2016-08-11 5:50 ` Ricardo Wurmus
2016-08-11 8:41 ` Chris Marusich
2016-08-11 10:14 ` Ricardo Wurmus
2016-08-11 10:51 ` Chris Marusich
2016-08-11 13:12 ` Ricardo Wurmus
2016-08-11 13:17 ` Ricardo Wurmus [this message]
2016-08-12 16:34 ` Chris Marusich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8737mbcun9.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=cmmarusich@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.