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

  • Done
  • quality assurance status badge
Details
3 participants
  • Leo Prikler
  • Maxim Cournoyer
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Leo Prikler
Severity
normal
L
L
Leo Prikler wrote on 31 Oct 2020 17:46
(address . guix-patches@gnu.org)
20201031164602.13152-1-leo.prikler@student.tugraz.at
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(+)

Toggle diff (50 lines)
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
R
R
Ricardo Wurmus wrote on 4 May 2021 09:46
(address . 44354@debbugs.gnu.org)
875yzzszyu.fsf@elephly.net
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
L
L
Leo Prikler wrote on 4 May 2021 11:15
3497ef1623c1a88c8fb9f09c068a078ba857e25f.camel@student.tugraz.at
Hi,

Am Dienstag, den 04.05.2021, 09:46 +0200 schrieb Ricardo Wurmus:
Toggle quote (4 lines)
> 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?

Toggle quote (4 lines)
> 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.

Toggle quote (5 lines)
> 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.

Toggle quote (3 lines)
> 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.
Toggle quote (2 lines)
> /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.
Toggle quote (1 lines)
> /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
R
R
Ricardo Wurmus wrote on 4 May 2021 11:58
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 44354@debbugs.gnu.org)
8735v2u8f3.fsf@elephly.net
Leo Prikler <leo.prikler@student.tugraz.at> writes:

Toggle quote (14 lines)
> 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.

Toggle quote (17 lines)
>> 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
L
L
Leo Prikler wrote on 4 May 2021 12:15
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 44354@debbugs.gnu.org)
3149f088b6e5c7d13b8f10616d7828cedc90ecba.camel@student.tugraz.at
Am Dienstag, den 04.05.2021, 11:58 +0200 schrieb Ricardo Wurmus:
Toggle quote (25 lines)
> 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.

Toggle quote (23 lines)
> > > 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
R
R
Ricardo Wurmus wrote on 4 May 2021 15:50
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 44354@debbugs.gnu.org)
87r1imsj5d.fsf@elephly.net
Leo Prikler <leo.prikler@student.tugraz.at> writes:

Toggle quote (40 lines)
>> > > 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.

Toggle quote (9 lines)
> 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
L
L
Leo Prikler wrote on 4 May 2021 17:49
(address . 44354@debbugs.gnu.org)
e3ee43cfa2e7666139a3022269b3dcb7cb716b63.camel@student.tugraz.at
Am Dienstag, den 04.05.2021, 15:50 +0200 schrieb Ricardo Wurmus:
Toggle quote (4 lines)
> 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).

Toggle quote (11 lines)
> > 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.

Toggle quote (5 lines)
> 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
M
M
Maxim Cournoyer wrote on 14 Sep 2022 15:27
Re: bug#44354: [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87pmfy13xh.fsf_-_@gmail.com
Hi Leo,

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

Toggle quote (57 lines)
> 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
R
R
Ricardo Wurmus wrote on 14 Sep 2022 19:49
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87k065lu64.fsf@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:

Toggle quote (63 lines)
> 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
M
M
Maxim Cournoyer wrote on 14 Sep 2022 20:38
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87h719ztqp.fsf@gmail.com
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (5 lines)
> 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.

[...]

Toggle quote (9 lines)
>> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 44354@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44354
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch