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

Previous Next

Package: guix-patches;

Reported by: Leo Prikler <leo.prikler <at> student.tugraz.at>

Date: Sat, 31 Oct 2020 16:57:02 UTC

Severity: normal

Tags: patch

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44354 in the body.
You can then email your comments to 44354 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Sat, 31 Oct 2020 16:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Leo Prikler <leo.prikler <at> student.tugraz.at>:
New bug report received and forwarded. Copy sent to guix-patches <at> gnu.org. (Sat, 31 Oct 2020 16:57:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: guix-patches <at> gnu.org
Subject: [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
Date: Sat, 31 Oct 2020 17:46:03 +0100
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





Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Tue, 04 May 2021 07:48:01 GMT) Full text and rfc822 format available.

Message #8 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: 44354 <at> debbugs.gnu.org
Subject: [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 09:46:49 +0200
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




Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Tue, 04 May 2021 09:16:02 GMT) Full text and rfc822 format available.

Message #11 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Ricardo Wurmus <rekado <at> elephly.net>, 44354 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 11:15:05 +0200
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





Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Tue, 04 May 2021 10:00:02 GMT) Full text and rfc822 format available.

Message #14 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 44354 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 11:58:56 +0200
Leo Prikler <leo.prikler <at> 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




Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Tue, 04 May 2021 10:16:01 GMT) Full text and rfc822 format available.

Message #17 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 44354 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 12:15:16 +0200
Am Dienstag, den 04.05.2021, 11:58 +0200 schrieb Ricardo Wurmus:
> Leo Prikler <leo.prikler <at> 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





Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Tue, 04 May 2021 13:51:01 GMT) Full text and rfc822 format available.

Message #20 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 44354 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 15:50:06 +0200
Leo Prikler <leo.prikler <at> 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




Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Tue, 04 May 2021 15:50:02 GMT) Full text and rfc822 format available.

Message #23 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Ricardo Wurmus <rekado <at> elephly.net>, Raghav Gururajan
 <rg <at> raghavgururajan.name>
Cc: 44354 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Tue, 04 May 2021 17:49:23 +0200
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





Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Wed, 14 Sep 2022 13:29:02 GMT) Full text and rfc822 format available.

Message #26 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: Ricardo Wurmus <rekado <at> elephly.net>,
 Raghav Gururajan <rg <at> raghavgururajan.name>, 44354 <at> debbugs.gnu.org
Subject: Re: bug#44354: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Wed, 14 Sep 2022 09:27:54 -0400
Hi Leo,

Leo Prikler <leo.prikler <at> 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




Information forwarded to guix-patches <at> gnu.org:
bug#44354; Package guix-patches. (Wed, 14 Sep 2022 17:54:02 GMT) Full text and rfc822 format available.

Message #29 received at 44354 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 Raghav Gururajan <rg <at> raghavgururajan.name>, 44354 <at> debbugs.gnu.org
Subject: Re: bug#44354: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Wed, 14 Sep 2022 19:49:49 +0200
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 <at> 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 sent to Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
You have taken responsibility. (Wed, 14 Sep 2022 18:39:02 GMT) Full text and rfc822 format available.

Notification sent to Leo Prikler <leo.prikler <at> student.tugraz.at>:
bug acknowledged by developer. (Wed, 14 Sep 2022 18:39:02 GMT) Full text and rfc822 format available.

Message #34 received at 44354-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 Raghav Gururajan <rg <at> raghavgururajan.name>, 44354-done <at> debbugs.gnu.org
Subject: Re: bug#44354: [PATCH] gnu: gnome-deskop-service-type: Set
 GUIX_GTK*_IM_MODULE_FILE.
Date: Wed, 14 Sep 2022 14:38:38 -0400
Ricardo Wurmus <rekado <at> 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




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 13 Oct 2022 11:24:11 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 167 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.