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

  • Open
  • quality assurance status badge
Details
2 participants
  • iyzsong
  • Leo Prikler
Owner
unassigned
Submitted by
iyzsong
Severity
normal
I
I
iyzsong wrote on 6 Dec 2020 06:40
(address . guix-patches@gnu.org)(name . ???)(address . iyzsong@member.fsf.org)
TYAP286MB018580C92BF3E9783BD56362A3CF0@TYAP286MB0185.JPNP286.PROD.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!


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
I
I
iyzsong wrote on 6 Dec 2020 07:15
[PATCH 1/2] profiles: Load application specific startup files.
(address . 45064@debbugs.gnu.org)(name . ???)(address . iyzsong@member.fsf.org)
TYAP286MB01857F3A772A5768FC7EC801A3CF0@TYAP286MB0185.JPNP286.PROD.OUTLOOK.COM
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(-)

Toggle diff (25 lines)
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
I
I
iyzsong wrote on 6 Dec 2020 07:15
[PATCH 2/2] profiles: gtk-im-modules: Set environment variables for input methods.
(address . 45064@debbugs.gnu.org)(name . ???)(address . iyzsong@member.fsf.org)
TYAP286MB01853FA44EBA3C46C5CCE754A3CF0@TYAP286MB0185.JPNP286.PROD.OUTLOOK.COM
From: ??? <iyzsong@member.fsf.org>

* guix/profiles.scm (gtk-im-modules): Set 'GUIX_GTK2_IM_MODULE_FILE' and
'GUIX_GTK3_IM_MODULE_FILE' via profile startup files.
---
guix/profiles.scm | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

Toggle diff (32 lines)
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 1b15257210..c998329e8a 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1151,7 +1151,10 @@ for both major versions of GTK+."
(map (cut string-append <> prefix "/immodules")
'#$(manifest-inputs manifest)))))
(modules (append-map (cut find-files <> "\\.so$")
- moddirs)))
+ moddirs))
+ (im-env (string-append "GUIX_GTK" #$major "_IM_MODULE_FILE"))
+ (envfile (string-append #$output "/etc/profile.d/gtk"
+ #$major "-im-modules.sh")))
;; Generate a new immodules cache file.
(mkdir-p (string-append #$output prefix))
@@ -1167,7 +1170,12 @@ for both major versions of GTK+."
(write-char (read-char pipe) out))))
#t)
(lambda ()
- (close-pipe pipe)))))))))
+ (close-pipe pipe)))
+ ;; Set environment variable for GTK+ input method modules.
+ (mkdir-p (dirname envfile))
+ (with-output-to-file envfile
+ (lambda ()
+ (simple-format #t "export ~a=~a\n" im-env outfile)))))))))
;; Don't run the hook when there's nothing to do.
(let* ((pkg-gtk+ (module-ref ; lazy reference
--
2.29.2
L
L
Leo Prikler wrote on 7 Dec 2020 13:09
Re: [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files
(name . ???)(address . iyzsong@member.fsf.org)
72dca2daaef417e9fef63e43f16eb76fe215f066.camel@student.tugraz.at
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:
Toggle quote (28 lines)
> 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(-)
>
?
?
??? wrote on 7 Dec 2020 14:55
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
TYAP286MB01850D310F024AF85AAB129DA3CE0@TYAP286MB0185.JPNP286.PROD.OUTLOOK.COM
Leo Prikler <leo.prikler@student.tugraz.at> writes:

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

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

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

Toggle quote (1 lines)
> 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?

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


Toggle quote (3 lines)
>
> 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!
L
L
Leo Prikler wrote on 7 Dec 2020 15:47
(name . ???)(address . iyzsong@outlook.com)
5dff940dcf1ba6d6b4facfa9eb1167f23c6add04.camel@student.tugraz.at
Hello,

Am Montag, den 07.12.2020, 21:55 +0800 schrieb ???:
Toggle quote (5 lines)
> [...]
> > 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`.

Toggle quote (17 lines)
> > 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?

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

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 45064
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