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

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

[Leo Prikler]

This makes it, so that GNOME can handle system-wide input methods installed
by adding them to the gnome package, to the operating system packages, or
to some other profile-service.  An example would be a system-wide installation
of ibus along with input methods like ibus-anthy or ibus-rime.

* gnu/services/desktop.scm (gnome-environment): New variable.
(gnome-desktop-service-type)[extensions]: Use it here.
---
 gnu/services/desktop.scm | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 265cf9f35f..8a571aacb0 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -918,12 +918,43 @@ rules."
            "gnome-system-monitor"
            "gvfs"))))
 
+(define (gnome-environment config)
+  (let* ((lib "/run/current-system/profile/lib")
+         (im-module-files
+          `(("3"
+             "GUIX_GTK3_IM_MODULE_FILE"
+             .
+             ,(string-append lib "/gtk-3.0/3.0.0/immodules-gtk3.cache"))
+            ("2"
+             "GUIX_GTK2_IM_MODULE_FILE"
+             .
+             ,(string-append lib "/gtk-2.0/2.10.0/immodules-gtk2.cache"))))
+         (versions
+          (filter-map
+           (match-lambda
+             ((_ pkg)
+              (and (package? pkg)
+                   (string=? (package-name pkg) "gtk+")
+                   (version-major (package-version pkg))))
+             ((_ pkg "out")
+              (and (package? pkg)
+                   (string=? (package-name pkg) "gtk+")
+                   (version-major (package-version pkg))))
+             (_ #f))
+           (package-transitive-inputs (gnome-package config)))))
+    (filter-map
+     (lambda (version)
+       (assoc-ref im-module-files version))
+     (delete-duplicates versions))))
+
 (define gnome-desktop-service-type
   (service-type
    (name 'gnome-desktop)
    (extensions
     (list (service-extension polkit-service-type
                              gnome-polkit-settings)
+          (service-extension session-environment-service-type
+                             gnome-environment)
           (service-extension profile-service-type
                              (compose list
                                       gnome-package))))
-- 
2.29.1

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

[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.

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.

Can we take a step back and come to an understanding of how ibus 
in Gnome is supposed to work?  Ibus in Gnome is (supposed to be) 
more “integrated” than in other environments, which means that we 
should first aim to understand what Gnome attempts to do with 
ibus.

We should also take into account dconf keys, such as these:

/desktop/ibus/
/org/gnome/desktop/input-sources/mru-sources
/org/gnome/desktop/input-sources/sources
/org/gnome/desktop/interface/gtk-im-module

What do you think?

-- 
Ricardo

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

[Leo Prikler]

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?

> 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.

> Can we take a step back and come to an understanding of how ibus 
> in Gnome is supposed to work?  Ibus in Gnome is (supposed to be) 
> more “integrated” than in other environments, which means that we 
> should first aim to understand what Gnome attempts to do with 
> ibus.
As far as I know, GNOME should recognize ibus as one of its input
modules and then offer appropriate input sources in its settings.  The
specifics are handled by gsd-keyboard-manager, at least as far as
setting these is concerned.  How the settings are interpreted is
probably a matter of GtkIMContext, which at some point hands off
control to ibus IIUC.

> We should also take into account dconf keys, such as these:
> 
> /desktop/ibus/
This seems to contain settings, that IBus wants to know about,
including stuff like what Emojis you last typed for the completion UI
and so on, and so forth.  Of particular interest here is probably the
key '/desktop/ibus/general/preload-engines', which lists all engines to
load at startup.
> /org/gnome/desktop/input-sources/mru-sources
> /org/gnome/desktop/input-sources/sources
These are lists of tuples, which are either ('xkb', VARIANT) or
('ibus', ENGINE).  As far as I know, the latter won't work correctly
without GNOME knowing about ibus existing, for which I patch GUIX_GTK*_IM_MODULE_FILE.
> /org/gnome/desktop/interface/gtk-im-module
This one's likely set to "ibus" inside an ibus setup.  In particular,
gsd-keyboard-manager sets it to "ibus" if it notices any of the input-
sources to contain an ibus engine and to "gtk-im-context-simple"
otherwise.  I'm sure there would be more elegant solutions, but that's
the one they chose.

Regards,
Leo

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

[Ricardo Wurmus]

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

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

[Leo Prikler]

Am Dienstag, den 04.05.2021, 11:58 +0200 schrieb Ricardo Wurmus:
> 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 think the reason why this might not work if you're putting things
into ~/.guix-profile is because that IM_MODULE_FILE is incomplete. 
Compare its contents against the one where everything is built into the
system, there will be huge differences.

> > > 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.
What is a "user process with user configuration" here?  The way I
understand those words, is that
a. the process is launched under the user's account, and
b. the configuration for that process lies in the user's directory.
Certainly, those two hold for ibus.  But they also hold for gnome,
which should not be inherently global either by the above argument. 
Yet managing gnome system-wide is significantly easier than managing it
per-user.

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.

Regards,
Leo

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

[Ricardo Wurmus]

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

>> > > 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.
> What is a "user process with user configuration" here?  The way 
> I
> understand those words, is that
> a. the process is launched under the user's account, and
> b. the configuration for that process lies in the user's 
> directory.
> Certainly, those two hold for ibus.  But they also hold for 
> gnome,
> which should not be inherently global either by the above 
> argument. 
> Yet managing gnome system-wide is significantly easier than 
> managing it
> per-user.

“easier” is not the question here.  We have always tried to avoid 
giving special importance to the system profile.  It’s a matter of 
flexibility.  Users on a shared system should have the option to 
have their own set of input methods.

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.

> 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.

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.

-- 
Ricardo

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

[Leo Prikler]

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.

Regards,
Leo

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

[Maxim Cournoyer]

Hi Leo,

Leo Prikler <leo.prikler@student.tugraz.at> 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?

Thanks,

Maxim

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

[Ricardo Wurmus]

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

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

[Maxim Cournoyer]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Maxim and Liliana,
>
> I hardly remember what this was about :)  But I can report that today
> ibus-libpinyin works for me.

Yes, it works for me too, not for pinyin but for anthy.

[...]

>> 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).

You are right.  Guix Home should provide a nice way to declare home
things, which it does, but not be a requirement to get software working
out of the box.

I'll close the ticket now.

Thanks!

Maxim