unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Leo Prikler <leo.prikler@student.tugraz.at>
Cc: 44354@debbugs.gnu.org
Subject: [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 11:58:56 +0200	[thread overview]
Message-ID: <8735v2u8f3.fsf@elephly.net> (raw)
In-Reply-To: <3497ef1623c1a88c8fb9f09c068a078ba857e25f.camel@student.tugraz.at>


Leo Prikler <leo.prikler@student.tugraz.at> writes:

> Hi,
>
> Am Dienstag, den 04.05.2021, 09:46 +0200 schrieb Ricardo Wurmus:
>> Hi Leo,
>> 
>> I haven’t been able to get ibus-libpinyin to work even when 
>> these 
>> variables are set.  I know that these variables used to work 
>> once.
> "Used to work" in what sense?  Did ibus-libpinyin work for you 
> or
> someone else with these variables set and now it's no longer 
> working?

Yes.

IIRC I patched GTK back in the day to respect these extra 
variables.  I did that because that made things work.  This 
predates at least two upgrades to Gnome and the decision on 
Gnome’s part to “integrate” ibus more tightly; I don’t know 
exactly when things broke because all I know is that when I 
returned to Guix after a months-long hiatus things no longer 
worked.

>> I don’t know if setting them is the correct thing to do for 
>> Gnome. 
>> This patch would also only work for system-wide installations 
>> of 
>> input methods.  Input methods that have been installed in a 
>> user 
>> profile would not be part of the cache files.
> I'm not sure we can expect things to "just work" with ibus in 
> the user
> profile.  As far as I'm aware, we don't expect GDM to find the 
> user's
> custom gnome installation without some hacking on their part, so 
> I
> don't understand why we would expect GNOME to find ibus in a 
> similar
> setup.

Because it worked just like that before.

Ibus should be a user process with user configuration.  This is 
not inherently global, so only making it work with globally 
installed input methods is a restriction that I think we should 
aim to do without.

-- 
Ricardo




  reply	other threads:[~2021-05-04 10:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-31 16:46 [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE Leo Prikler
2021-05-04  7:46 ` Ricardo Wurmus
2021-05-04  9:15   ` Leo Prikler
2021-05-04  9:58     ` Ricardo Wurmus [this message]
2021-05-04 10:15       ` Leo Prikler
2021-05-04 13:50         ` Ricardo Wurmus
2021-05-04 15:49           ` Leo Prikler
2022-09-14 13:27             ` Maxim Cournoyer
2022-09-14 17:49               ` Ricardo Wurmus
2022-09-14 18:38                 ` bug#44354: " Maxim Cournoyer

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735v2u8f3.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=44354@debbugs.gnu.org \
    --cc=leo.prikler@student.tugraz.at \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).