bug#48796: Guix on Debian 11 - Cant run or find applications from Guix in Desktop Menus

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 10069 bytes --]

Hi Liliana Marie,

thank you for your heads up!

I confess I'm pretty much confused about "Freedesktop.org's xdg menu
system" because I thought it's now a cross-distro standard that should
work out of the box without much tinkering by the distro maintainers
and/or by the user.  There is a non zero chance that it does depend on
poor implementation or documentation, and for sure I'm not the only one
that is experiencing issues in this regard[1].  There is obviously a non
zero chance it depends on my poor understanding, please forgive me in
this case.

This situation (obviously) does /not/ depend on Guix, it depends on the
Xsession setup and "xdg menu system" (and lack of documentation?) of the
foreign distro side.

I just think that if Guix (the package manager) cannot automate desktop
integration on all foreign distros then it should be stated in the
manual, possibly explaining why and pointing users to the foreign distro
documentation.

Anyway, I still think (hope) that we can "fill the gap" since we
probably have al the pieces (env and information) and we probably "just"
need to connect the dots to have the whole picture... working
cross-distro I mean.

To add a little bit of context (and highlight it's not an issue just for
Guix as a package manager) I found this bug reports interesting:

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927907
flatpak directories not added to XDG_DATA_DIRS on Plasma + Wayland
(still open, last update 2022-04-16)

2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931776
snapd: Installed snaps do not appear in desktop launcher in Debian
buster.
(still open, last update 2022-04-22)

3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647427
XDG_DATA_DIRS not set when using openbox-gnome-session
(resolved on 2013-07-23)

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

>> > It even set XDG_DATA_DIRS, which should allow integration with the
>> > GNOME Shell and other graphical dashboards.
>> 
>> No: this does not work, for three reasons:
>> 
>> 1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not
>> sourced/executed in a graphical session (graphical shell?), we need
>> to ~/.xsessionrc to configure that environment: am I wrong?
> Depends on your setup.  Some systemd setups don't source it,

So it depends on the /default/ systemd setup of the foreign distro,
Debian 11 in this case, because I did not customize it: please do you
know where I should check for the systemd specific documentation on "xdg
related stuff"?

The documentation I was able to find does not help me with systemd
config:

- https://wiki.debian.org/Xsession [2]

- https://wiki.debian.org/EnvironmentVariables#Using_graphical_display_manager

This statement (in https://wiki.debian.org/Xsession)

--8<---------------cut here---------------start------------->8---

Finally, note that the ~/.xsession file is only read if you are using a
Debian X session. If you login with gdm3 and choose a GNOME session, the
~/.xsession file will be ignored completely. (But you may still use
~/.xsessionrc.)

--8<---------------cut here---------------end--------------->8---

makes me wonder what (and why) is the differenxe betweeen a Gnome
Session and an LXDE one: shouldn't the setup be standard? It's the
systemd specific way to setup an xsession?

Also: https://manpages.org/xsession/5

By default, on Debian 11 this is the content of
/etc/X11/Xsession.options:

--8<---------------cut here---------------start------------->8---

# $Id: Xsession.options 189 2005-06-11 00:04:27Z branden $
#
# configuration options for /etc/X11/Xsession
# See Xsession.options(5) for an explanation of the available options.
allow-failsafe
allow-user-resources
allow-user-xsession
use-ssh-agent
use-session-dbus

--8<---------------cut here---------------end--------------->8---

Do I miss some specific systemd Debian 11 xdg related documentation?

> but note that you can work around that by editing the offending file.

Please can you point me to the offending file?

> More importantly...
>
>> 2. XDG_DATA_DIRS gets someway hard reset by "something" to this
>> value:
>> 
>> XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/men
>> u-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-
>> xdg/
> I would investigate what actually "resets" this.  If it survives
> XDG_DATA_DIRS=blah $SHELL, then it's in the stuff your shell sources.

Actually if I give that command in a terminal I get
"XDG_DATA_DIRS=blah", but I'm pretty sure there is nothing in the stuff
of my shell sources that resets XDG_DATA_DIRS

> If it doesn't, then you probably just experience (1).

Yes: there is something in the default systemd/xsession configuration
of Debian 11 that resets XDG_DATA_DIR.

Please is there some user with a default Debian 11 xsession
configuration that can try to reproduce this?

Am I the only one to experience this XDG_DATA_DIR reset issue?

>> (I found workaround, see below)
>> 
>> 3. desktop menus (I tested LXDE and Mate, not Gnome Shell) are not
>> updated
> We hacked our Gnome Shell package to do this on Guix – naturally this
> won't work for foreign systems or other packages.

OK thank you, now I understand how it works.

I still have not found some time to check how Debian packages are
live-updating the desktop menus, AFAIK that update works
cross-desktop-environment and I'd like to know:

1. is that also a cross-distro standard?

2. why "xdg-desktop-menu forceupdate" does not work for user installed
*.desktop menus?

3. is there any other CLI that allows users to uptate their graphical
menus after having "manually installed" (write the right file in the
right folder) a *.desktop file?

>> [...]
>> The main point of this workaround is that I configure XDG_DATA_HOME,
>> described in the specifications:
> And that is evil.

Please can you expand what do you mean with "evil"?

I as told (did I told?) I found that information in the "XDG Base
Directory Specification" [3] 

Also, the "9.4.10. Starting a program from GUI" [4] current Debian
manual states:

--8<---------------cut here---------------start------------->8---

This is an oversimplified description. The *.desktop files are scanned as follows.

The desktop environment sets $XDG_DATA_HOME and $XDG_DATA_DIR environment variables. For example, under the GNOME 3:

$XDG_DATA_HOME is unset. (The default value of $HOME/.local/share is used.)

$XDG_DATA_DIRS is set to /usr/share/gnome:/usr/local/share/:/usr/share/.

So the base directories (see XDG Base Directory Specification) and the applications directories are as follows.

$HOME/.local/share/ → $HOME/.local/share/applications/

/usr/share/gnome/ → /usr/share/gnome/applications/

/usr/local/share/ → /usr/local/share/applications/

/usr/share/ → /usr/share/applications/

The *.desktop files are scanned in these applications directories in this order.

[Tip]	Tip
A user custom GUI menu entry can be created by adding a *.desktop file in the $HOME/.local/share/applications/ directory.

[Tip]	Tip
Similarly, if a *.desktop file is created in the autostart directory under these base directories, the specified program in the *.desktop file is executed automatically when the desktop environment is started. See Desktop Application Autostart Specification.

--8<---------------cut here---------------end--------------->8---

Also, the Freedesktop.org "Desktop Menu Specification" chapter
"C. Integrating your application in the menus" [5] documents how to add
menu items; it states:

--8<---------------cut here---------------start------------->8---

If an application is intended to be installed by an unprivileged user for exclusive use by that user only then $XDG_DATA_HOME should be used as value for datadir and $XDG_CONFIG_HOME should be used as value for sysconfdir. If $XDG_DATA_HOME is not set, the default value of $HOME/.local/share should be used for it. If $XDG_CONFIG_HOME is not set, the default value of $HOME/.config should be used for it.

--8<---------------cut here---------------end--------------->8---

Reading the above it seems perfectly legit to customize XDG_DATA_HOME
pointing that variable to any user directory I need to add custom GUIX
menu entries... and I let handle that menu entries to my guix profile:
do I miss something?

Should I also customize $XDG_CONFIG_HOME to point to a specific
directory different from $HOME/.config?

>> [...]
>> Anyway to make the new installed *.desktop files appear in the menu,
>> I have to logout and login again: I've still not found a command (or
>> configuration) to update the menu, "xdg-desktop-menu forceupdate"
>> does not work.
> Should it?  It might only honor XDG_DATA_DIRS and ignore XDG_DATA_HOME
> by accident.

AFAIU xdg-desktop-menu is supposed to also update user menus

> Other than that, restarting your shell (if running on X) might be a
> more lightweight way of refreshing the menu.

Restarting the shell means restarting the desktop environment?

I know how to do it with i3 (reload config) but I don't know hot to do
it with LXDE (or mate, Gnome3, ecc.)

Cheers.

Gio'



[1] as I already wrote, I don't use any desktop environment graphical
menu so I rarely experience this issues, but when trying to help other
users I still cannot find a deterministic solution to this class of
issues.

[2] it also points to
https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_the_x_window_system
but that node is /not/ present on a recent manual

[3]
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

[4] https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_starting_a_program_from_gui

[5] https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#third-party-howto

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]