Caleb Herbert writes: > On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote: >> Mikhail Kryshen skribis: >> >> > Ludovic Courtès writes: >> > >> >>> Is there a way to make Trisquel's GNOME and its main menu aware of >> >>> programs installed with Guix? >> >> >> >> It should be possible, but I don’t know how. Anyone? >> > >> > I don't use Trisquel, but this works for GNOME in Fedora: >> > >> > ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix >> > >> > You might also want to copy or symlink application icons from >> > ~/.guix-profile/share/icons to ~/.local/share/icons > > I have a better way. This did not work for me on Trisquel. > > My experience: Apps appeared in the main menu, but GNOME was not aware > of them. Icons were missing, Emacs would never show up in "Open With", > and I couldn't launch Mumble from Run Application (Alt+F2). > > Solution: > https://trisquel.info/en/forum/guix-trisquel#comment-122789 > (Thanks, ADFENO!) > > GNOME sees apps and icons now! This sounds very similar to https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html in which the interaction between Guix-installed packages (emacs, in my case) and the XDG_DATA_DIRS environment variable caused the UI (including icons) to display incorrectly. It would be nice to solve this in general for Guix-installed applications on foreign distros. Do you have any ideas about how we can solve it? The Guix-installed emacs, in particular, has some wrapper scripts: --8<---------------cut here---------------start------------->8--- [0] marusich@garuda:~ $ cat $(readlink $(which emacs)) #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash export XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" export GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" export GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" exec -a "$0" "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3" "$@" [0] marusich@garuda:~ $ cat /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3 #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash export XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" export GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" export GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" exec -a "$0" "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real" "$@" [0] marusich@garuda:~ $ file /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped, with debug_info [0] marusich@garuda:~ $ --8<---------------cut here---------------end--------------->8--- In particular, note how the two wrapper scripts add (the same) store entries to the front of the existing XDG_DATA_DIRS environment variable. I was able to solve my emacs UI problem by removing the "/usr/share/" entry from XDG_DATA_DIRS. You were able to solve your problem by adding ${HOME}/.guix-profile/share to the front of XDG_DATA_DIRS and adding the foreign distro's XDG_DATA_DIRS (including "/usr/share/" to the end). I feel like these clues are pointing to something, but I'm not yet sure what. Do you have any good ideas? I think it's fine (although I wish it weren't necessary at all) to require users to customize their environment to enable all features of Guix-installed applications on a foreign distro (features like properly displayed icons, locales, etc.) . However, asking users to configure XDG_DATA_DIRS seems significantly more complicated, due to problems like these, and also like bug 26202: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202 I really hope we can figure out a way to get things that rely on XDG_DATA_DIRS to work better out of the box. > Remaining hurdles: > * Buttons don't show up, themes don't match: > https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png Could this be the same issue that I saw with emacs? I mentioned this above, but here's the link again: https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html > * Fcitx Mozc input method for Japanese does not work in Guix apps Can you tell us more about your use case? Are you trying to install fcitx etc. via Guix, and then use it to type in Japanese within Guix-installed applications (do they use GTK, or something else)? Or did you install fcitx etc. using the foreign distro's package manager (e.g., apt-get), and now you are trying to use that IME to type in Japanese within Guix-installed apps? The interaction between an IME and its environment is tricky to get right and depends on a lot of factors, so I expect it might require a non-trivial amount of work to make it so that all Guix-installed apps will correctly make use of an IME that is installed and managed by the foreign distro. FWIW, I have been able to get Japanese input working in GuixSD in all apps using ibus and ibus-anthy. I haven't yet tried to get Japanese input working in Guix-installed applications on a foreign distro. -- Chris