unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
@ 2020-10-31 16:46 Leo Prikler
  2021-05-04  7:46 ` Ricardo Wurmus
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Prikler @ 2020-10-31 16:46 UTC (permalink / raw)
  To: 44354

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





^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  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
  0 siblings, 1 reply; 10+ messages in thread
From: Ricardo Wurmus @ 2021-05-04  7:46 UTC (permalink / raw)
  To: 44354

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2021-05-04  7:46 ` Ricardo Wurmus
@ 2021-05-04  9:15   ` Leo Prikler
  2021-05-04  9:58     ` Ricardo Wurmus
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Prikler @ 2021-05-04  9:15 UTC (permalink / raw)
  To: Ricardo Wurmus, 44354

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2021-05-04  9:15   ` Leo Prikler
@ 2021-05-04  9:58     ` Ricardo Wurmus
  2021-05-04 10:15       ` Leo Prikler
  0 siblings, 1 reply; 10+ messages in thread
From: Ricardo Wurmus @ 2021-05-04  9:58 UTC (permalink / raw)
  To: Leo Prikler; +Cc: 44354


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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2021-05-04  9:58     ` Ricardo Wurmus
@ 2021-05-04 10:15       ` Leo Prikler
  2021-05-04 13:50         ` Ricardo Wurmus
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Prikler @ 2021-05-04 10:15 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 44354

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2021-05-04 10:15       ` Leo Prikler
@ 2021-05-04 13:50         ` Ricardo Wurmus
  2021-05-04 15:49           ` Leo Prikler
  0 siblings, 1 reply; 10+ messages in thread
From: Ricardo Wurmus @ 2021-05-04 13:50 UTC (permalink / raw)
  To: Leo Prikler; +Cc: 44354


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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2021-05-04 13:50         ` Ricardo Wurmus
@ 2021-05-04 15:49           ` Leo Prikler
  2022-09-14 13:27             ` Maxim Cournoyer
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Prikler @ 2021-05-04 15:49 UTC (permalink / raw)
  To: Ricardo Wurmus, Raghav Gururajan; +Cc: 44354

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2021-05-04 15:49           ` Leo Prikler
@ 2022-09-14 13:27             ` Maxim Cournoyer
  2022-09-14 17:49               ` Ricardo Wurmus
  0 siblings, 1 reply; 10+ messages in thread
From: Maxim Cournoyer @ 2022-09-14 13:27 UTC (permalink / raw)
  To: Leo Prikler; +Cc: Ricardo Wurmus, Raghav Gururajan, 44354

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* [bug#44354] [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2022-09-14 13:27             ` Maxim Cournoyer
@ 2022-09-14 17:49               ` Ricardo Wurmus
  2022-09-14 18:38                 ` bug#44354: " Maxim Cournoyer
  0 siblings, 1 reply; 10+ messages in thread
From: Ricardo Wurmus @ 2022-09-14 17:49 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: Liliana Marie Prikler, Raghav Gururajan, 44354

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#44354: [PATCH] gnu: gnome-deskop-service-type: Set GUIX_GTK*_IM_MODULE_FILE.
  2022-09-14 17:49               ` Ricardo Wurmus
@ 2022-09-14 18:38                 ` Maxim Cournoyer
  0 siblings, 0 replies; 10+ messages in thread
From: Maxim Cournoyer @ 2022-09-14 18:38 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Liliana Marie Prikler, Raghav Gururajan, 44354-done

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-09-14 18:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2022-09-14 18:38                 ` bug#44354: " Maxim Cournoyer

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