unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>,
	Raghav Gururajan <rg@raghavgururajan.name>,
	44354@debbugs.gnu.org
Subject: [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
Date: Wed, 14 Sep 2022 19:49:49 +0200	[thread overview]
Message-ID: <87k065lu64.fsf@elephly.net> (raw)
In-Reply-To: <87pmfy13xh.fsf_-_@gmail.com>

Hi Maxim and Liliana,

I hardly remember what this was about :)  But I can report that today
ibus-libpinyin works for me.

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Liliana writes:
>
>> Am Dienstag, den 04.05.2021, 15:50 +0200 schrieb Ricardo Wurmus:
>>> Gnome uses dbus extensively, so it should be able to talk to the 
>>> user’s ibus daemon over dbus and offer available input methods 
>>> this way.  Perhaps we can get rid of static IM_MODULE_FILEs and 
>>> the problem of monolithic cache files, etc.
>> That would probably work in some capacity, but
>> a. It seems ibus does not really export a usable dbus-interface (at
>> least not according to d-feet).  While the communication does appear to
>> happen via dbus, there are no methods exported, so it's some kind of
>> black magic.
>> b. Even if it did, the code to communicate to ibus via dbus would still
>> need to be wrapped into a GtkIMContext.  Perhaps that can be
>> implemented as part of Gnome, but I don't know how quickly it would be
>> done.
>>
>> In short, I think there's some tight coupling between IBus client and
>> server going on, which makes Gnome rely on the ibus IMContext
>> implementation.  We could likely try to propagate just the client code
>> from our GNOME package (we still would need to add it as an IM_MODULE,
>> but you could use your own ibus at least, provided it's compatible with
>> the system ibus).
>>
>>> > Also note, that my patch would not bar you from setting
>>> > GUIX_GTK*_IM_MODULE_FILE to something else if you indeed have a 
>>> > local
>>> > ibus setup.  I'd even go so far as to argue, that it doesn't 
>>> > make your
>>> > setup more difficult at all.  All it does is make things easier 
>>> > for
>>> > those who want a global gnome+ibus setup.
>>> 
>>> There may be a misunderstanding here: I don’t *have* a setup.  As 
>>> it is, ibus(-libpinyin) does not work reliably with Gnome.
>> I wasn't talking about your problems with ibus-libpinyin here, it was
>> instead meant as a general statement about Guix users currently setting
>> those variables somewhere to appease Gnome.  Their settings would not
>> be invalidated by this patch.  I'm still interested into what causes
>> the libpinyin variant to fail in this setup, because I doubt it's a GTK
>> thing.
>>
>>> My main point here is that I’d rather we take a step back to see 
>>> if all this GUIX_GTK* variable patching is still worth doing, and 
>>> whether there are better ways we could achieve a reliable 
>>> configuration of ibus — no matter if that’s a global configuration 
>>> or a per-user one.
>> IIRC GUIX_GTK* is just a way of not clobbering GTK_IM_MODULE_FILE. 
>> Having that probably makes some sense.  As for requiring it for a
>> proper ibus setup, I do agree, perhaps it's possible to do without it. 
>> I've pinged Raghav, maybe they already know whether Gnome 40 brings
>> improvements in that regard.
>>
>> Perhaps another way of managing these variables if we indeed find them
>> to be needed would be to move the configuration into a 'guix home'
>> module.  When I wrote this patch, there were no plans of upstreaming it
>> yet, but if it's possible to set per-user environment variables via
>> guix home, that might be preferable to a system-wide setting.
>
> Ricardo seems to have good arguments about doing things differently (on
> the user side).  With Guix Home now part of Guix, can we close this
> issue and revisit it?

I don’t know how Guix Home fits into the conversation here.  I’m also a
little worried about making the use of Guix Home mandatory for features
like input methods (and sound, because that’s what I hear is recommended
for pipewire).


-- 
Ricardo




  reply	other threads:[~2022-09-14 18:07 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
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 [this message]
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=87k065lu64.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=44354@debbugs.gnu.org \
    --cc=liliana.prikler@ist.tugraz.at \
    --cc=maxim.cournoyer@gmail.com \
    --cc=rg@raghavgururajan.name \
    /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).