[bug#45064] [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files

[bug#45064] [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files

[iyzsong]

From: 宋文武 <iyzsong@member.fsf.org>

Hello, Guix!

To use GTK+ input methods, currently we need set
‘GUIX_GTK2_IM_MODULE_FILE’ and ‘GUIX_GTK3_IM_MODULE_FILE’ manually in
.xsession or .bash_profile, we also having a patch [1] that set them
for gnome via ‘gnome-desktop-service-type’.  But I think the right
place to set them is the ‘gtk-im-modules’ profile hook, so the first
patch make ‘etc/profile’ source files in ‘etc/profile.d/*.sh’, and the
second patch add ‘etc/profile.d/gtk2-im-modules.sh’ and
‘etc/profile.d/gtk3-im-modules.sh’.  The first patch is also useful
for packages that provide profile startup files (eg: nix).

Thanks!

[1] <https://issues.guix.gnu.org/44354>

Sou Bunnbu (宋文武) (2):
  profiles: Load application specific startup files.
  profiles: gtk-im-modules: Set environment variables for input methods.

 guix/build/profiles.scm | 13 ++++++++++++-
 guix/profiles.scm       | 12 ++++++++++--
 2 files changed, 22 insertions(+), 3 deletions(-)

-- 
2.29.2

[bug#45064] [PATCH 1/2] profiles: Load application specific startup files.

[iyzsong]

From: 宋文武 <iyzsong@member.fsf.org>

* guix/build/profiles.scm (build-etc/profile): Source application specific
startup files in 'etc/profile.d'.
---
 guix/build/profiles.scm | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/guix/build/profiles.scm b/guix/build/profiles.scm
index 67ee9b665a..25165e0edb 100644
--- a/guix/build/profiles.scm
+++ b/guix/build/profiles.scm
@@ -98,7 +98,17 @@ definitions for all the SEARCH-PATHS."
       (let ((variables (evaluate-search-paths search-paths
                                               (list output))))
         (for-each (write-environment-variable-definition port)
-                  (map (abstract-profile output) variables))))))
+                  (map (abstract-profile output) variables)))
+
+      (simple-format port "
+# Load application specific startup files.
+if test -d ~a/etc/profile.d; then
+    for script in ~a/etc/profile.d/*.sh; do
+        source \"$script\"
+    done
+    unset script
+fi
+\n" output output))))
 
 (define* (ensure-writable-directory directory
                                     #:key (symlink symlink))
-- 
2.29.2

[bug#45064] [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files

[Leo Prikler]

Hello, 宋文武!

As the author of [1] I might be a bit biased, but I have a few
questions regarding this patch set:
1. Will it correctly pick up IM_MODULE_FILEs at system level if you
also happen to have GTK+ applications installed at user level?
  a. What about multi-profile setups, where more than one profile
contains GTK+ applications?
  b. What about `guix environment`?
2. Which purpose would sourcing those files offer other than setting
environment variables?  What would be permissible actions?  Remember,
that those would be executed whenever the user spawns a shell, so while
you could put stuff like `fc-cache -r` in there, I personally think you
ought not to.

I believe a proper fix for GTK would be to allow setting multiple
IM_MODULE_FILEs instead of a single one and using search paths.  [1]
was merely meant to have a reasonable default when installing ibus
system-wide, it can not (and will not) help you if you also happen to
have stuff in another profile.

Regards,
Leo

Am Sonntag, den 06.12.2020, 13:40 +0800 schrieb iyzsong@outlook.com:
> From: 宋文武 <iyzsong@member.fsf.org>
> 
> Hello, Guix!
> 
> To use GTK+ input methods, currently we need set
> ‘GUIX_GTK2_IM_MODULE_FILE’ and ‘GUIX_GTK3_IM_MODULE_FILE’ manually in
> .xsession or .bash_profile, we also having a patch [1] that set them
> for gnome via ‘gnome-desktop-service-type’.  But I think the right
> place to set them is the ‘gtk-im-modules’ profile hook, so the first
> patch make ‘etc/profile’ source files in ‘etc/profile.d/*.sh’, and
> the
> second patch add ‘etc/profile.d/gtk2-im-modules.sh’ and
> ‘etc/profile.d/gtk3-im-modules.sh’.  The first patch is also useful
> for packages that provide profile startup files (eg: nix).
> 
> Thanks!
> 
> [1] <https://issues.guix.gnu.org/44354>
> 
> Sou Bunnbu (宋文武) (2):
>   profiles: Load application specific startup files.
>   profiles: gtk-im-modules: Set environment variables for input
> methods.
> 
>  guix/build/profiles.scm | 13 ++++++++++++-
>  guix/profiles.scm       | 12 ++++++++++--
>  2 files changed, 22 insertions(+), 3 deletions(-)
> 

[bug#45064] [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files

[宋文武]

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

> Hello, 宋文武!
>
> As the author of [1] I might be a bit biased, but I have a few
> questions regarding this patch set:
Hello, thanks for asking!

> 1. Will it correctly pick up IM_MODULE_FILEs at system level if you
> also happen to have GTK+ applications installed at user level?
Oh, if I have ibus in system profile, and no input methods but GTK+
applications in user profile, then it will be broken, as user's profile
was source later in '/etc/profile', replace the IM_MODULE_FILE from
system profile.  Need more think...

>   a. What about multi-profile setups, where more than one profile
> contains GTK+ applications?
Because only a single variable for all gtk+ versions, We can only hope
those GTK+ applications from different profiles can accept the same
input methods modules, this patch dosen't improve the situation.

>   b. What about `guix environment`?
For `guix environment`, it dosen't load `/etc/profile`, so this have no
effect, but maybe we should make it doing so?

> 2. Which purpose would sourcing those files offer other than setting
> environment variables?  What would be permissible actions?  Remember,
> that those would be executed whenever the user spawns a shell, so while
> you could put stuff like `fc-cache -r` in there, I personally think you
> ought not to.
Sure, for set environment variables, I can't came up with other
examples. It's just like support '/etc/profile.d', but there are some
packages (for now, only nix I think) that will set environment variables
outside of store and profile (NIX_PATH=$HOME/.nix-defexpr/channels, etc)
which would be difficult for search-paths.  I agree with you that
profile should not run things that modify files.


>
> I believe a proper fix for GTK would be to allow setting multiple
> IM_MODULE_FILEs instead of a single one and using search paths.
Our search paths can be a single file (eg: SSL_CERT_FILE) or mutiple
files, but we need to add it to all GTK+ input methods (only ibus and
fcitx, but it's like GST_PLUGIN_SYSTEM_PATH every where, not ideal), my
point is that set thoses environment varaibles once profile level is
better than set them many times each package.  If profile hook can
contribute to the search-paths of manifest, I'd go for it.

So in the end, this may only bring benifits for packages that came up
with profile scripts in etc/profile.d, and I need to think more for
multiple profiles...

Thank you!

[bug#45064] [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files

[Leo Prikler]

Hello,

Am Montag, den 07.12.2020, 21:55 +0800 schrieb 宋文武:
> [...]
> >   b. What about `guix environment`?
> For `guix environment`, it dosen't load `/etc/profile`, so this have
> no
> effect, but maybe we should make it doing so?
It may not load `/etc/profile`, but it will load
`$GUIX_ENVIRONMENT/etc/profile`.

> > 2. Which purpose would sourcing those files offer other than
> > setting
> > environment variables?  What would be permissible
> > actions?  Remember,
> > that those would be executed whenever the user spawns a shell, so
> > while
> > you could put stuff like `fc-cache -r` in there, I personally think
> > you
> > ought not to.
> Sure, for set environment variables, I can't came up with other
> examples. It's just like support '/etc/profile.d', but there are some
> packages (for now, only nix I think) that will set environment
> variables
> outside of store and profile (NIX_PATH=$HOME/.nix-defexpr/channels,
> etc)
> which would be difficult for search-paths.  I agree with you that
> profile should not run things that modify files.
I think another potential candidate if we were to head into that
direction might be flatpak, but should those packages not rather assume
meaningful default values if said variables are unset?

> > I believe a proper fix for GTK would be to allow setting multiple
> > IM_MODULE_FILEs instead of a single one and using search paths.
> Our search paths can be a single file (eg: SSL_CERT_FILE) or mutiple
> files, but we need to add it to all GTK+ input methods (only ibus and
> fcitx, but it's like GST_PLUGIN_SYSTEM_PATH every where, not ideal),
> my
> point is that set thoses environment varaibles once profile level is
> better than set them many times each package.  If profile hook can
> contribute to the search-paths of manifest, I'd go for it.
I think there might be a way to work around that.  First, create a
hidden package, that uses GTK+ as an input and propagates the immodules
as well as share/locale (for translation) towards its output (the
source can be empty). Add a search-path for GUIX_GTK*_IM_MODULE_FILE to
that package.  Propagate that input from ibus and fcitx.  Then make it
so that the IM module file builder looks for that package instead of
plain GTK+.

If you do everything right, the IM module file builder should only run
if a package, that adds an IM module is in the profile and that IM
module file will then be used to set GUIX_GTK*_IM_MODULE_FILE.

Regards,
Leo