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

[Leo Prikler <leo.prikler@student.tugraz.at>]

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