| Message ID | TYAP286MB018580C92BF3E9783BD56362A3CF0@TYAP286MB0185.JPNP286.PROD.OUTLOOK.COM |
|---|---|
| Headers | show |
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(-) >
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!
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
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(-)