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
next prev parent 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).