[bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.

[Ricardo Wurmus <rekado@elephly.net>]

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