[Suggestion] Integrate .desktop files in a more standard manner, similar to snaps, flatpak, nix etc

[codexMechanicus]

This is similar to a request I made before but is much better thought out and inline with standard XDG practice.

Getting to the point, distrobox app exports could better conform to standard practices by storing exported .desktop files in a directory specifically for distrobox exports, while still showing up in users menu's.

for example $HOME/.distrobox/share
or any where deemed a better location.

To ensure exports show up in the users desktop menus the paths would be added to the users XDG_DATA_DIRS
via a command such as:
`echo export 'XDG_DATA_DIRS=$HOME/.distrobox/share:$HOME/.share:"${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}" ' >> ~/.xsessionrc
(This command sets up default XDG_DATA_DIRS if they are not already set up)

The .desktop files could also be stored in container specific files .distrobox/ubuntu/share and symlinked to .distrobox/share or whatever the chosen path is. Which would help with issue #301 and allow these files to be deleted simply by deleting the folder.

There are reasons other applications that export .desktop files create their own directory and add the directory to XDG_DATA_DIRS, and making it easier to clean up and manage exports I expect is a key aspect of it. This is practised by GNOME devs and others who are involved in discussing XDG/freedesktop.org standards.

I think if this is not standard behaviour it should at least be an available option via config files, or app exports should accept a custom location so this can be implemented simply by users.

Stack Exchange answer where I got the idea: https://unix.stackexchange.com/questions/310666/nix-desktop-files

*PS: If this suggestion is approved of, I can implement it and submit a pull request.

[89luca89]

I really like this idea! It would make life a lot easier thanks 😄

I'll think on how to organize it, but ideas are welcome!

[89luca89]

What I was thinking is just that managing XDG_DATA_DIRS could be tricky for the installer:

if we're doing a rootful install (package or sudo ./install), we can just put a script in /etc/profile.d/distrobox.sh that sets up the variable
But if we're doing a rootless install (./install in $HOME), we need to find a way to add it to the user's profile without risking on messing up the ~/.profile file

EDIT: This will also be super-handy for the new generate-entry command 😃

[codexMechanicus]

I'm glad you like it Luca! I don't know what generate-entry is yet, (I'm intrigued) but I'm glad it helps there, it also shows that it's a solution which would help everything fall into place!

The command I gave doesn't require root privileges or is the issue the lack of permanence of that command? That the command needs to be triggered on login?

Yes, I did over look something in the initial post and the command I gave wasn't sufficient to make the change persistent, I came across something that is too hacky for my liking:

echo export 'XDG_DATA_DIRS=$HOME/.distrobox/share:$HOME/.share:"${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}" ' >> ~/.xsessionrc

Though it definitely works, is persistent and does not requite root privileges. However, it could lead us in the right direction, what is needed is a destination that more appropriate. I wonder how flatpak/snap and the rest go about this? A look at their source code may be in order there however they may well use root user permissions.

[89luca89]

echo export 'XDG_DATA_DIRS=$HOME/.distrobox/share:$HOME/.share:"${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}" ' >> ~/.xsessionrc

Yea I know, we could also use the ~/.profile file, but I'm keen to not touch other people's files if possible 😄

I wonder how flatpak/snap and the rest go about this? A look at their source code may be in order there however they may well use root user permissions.

They just drop the line in a file in /etc/profile.d/flatpak.sh, and that's sourced automatically at login
But that's the part that requires root

[sebastiencs]

For rootless install, a file could be added to ~/.config/environment.d/ ?

https://www.man7.org/linux/man-pages/man5/environment.d.5.html

[89luca89]

For rootless install, a file could be added to ~/.config/environment.d/ ?

https://www.man7.org/linux/man-pages/man5/environment.d.5.html

This seems to be systemd specific, and to work with systemd-units
Tried to use for the shell but didn't work

[codexMechanicus]

I'm keen to not touch other people's files if possible

There are a few suggestions here.
https://www.simplified.guide/linux/automatically-run-program-on-startup

A cron job to run the command might be best? Since it's part of Linux-utils and thus supported by sys-v as well as more niche init systems. Cron jobs execute commands as non-root users and I'm guessing it can be set up rootlessly also?

[luc14n0]

Instead of touching $XDG_DATA_DIRS, what about sticking with standard locations: /usr/share/applications/$XDG_DATA_HOME/applications and calling update-desktop-dabase to ensure they appear on the application menu?

We could either use .../applications or .../applications/distrobox/... if organizing by container is preferred.

I don't use distrobox-export but, just as an example, one could add a desktop file to launch gnome-terminal and automatically run a Ubuntu (or whichever distro they want) container inside Tmux:

1. Drop the desktop file in $XDG_DATA_HOME/applications, distrobox-Ubuntu-22.desktop in this example, with the following content:

[Desktop Entry]
Name=Ubuntu 22.04
GenericName=Distrobox Ubuntu 22.04
Comment=Launch Ubuntu 22.04 container
TryExec=gnome-terminal
Exec=gnome-terminal --maximize -- distrobox-enter -a '--env DISTROBOX=ubuntu' -n ubuntu -- tmux -L dbx-ubuntu new -s Hera
Icon=/home/luc14n0/Pictures/ubuntu-logo32.png
Type=Application
Categories=GNOME;GTK;System;TerminalEmulator;
StartupNotify=true
StartupWMClass=Gnome-terminal
X-GNOME-SingleWindow=false
Actions=preferences;

[Desktop Action preferences]
Name=Preferences
Exec=gnome-terminal --preferences

2. And finally call $ update-desktop-database $XDG_DATA_HOME/applications. A $ desktop-file-validate our-desktop-file.desktop can help us with checking if we're hurting any Desktop Entry specification. Both tools are provided by Freedesktop's desktop-file-utils package.

Now I have this neat puppy here:

[codexMechanicus]

@luc14n0
You can use the new command distrobox generate-entry to add a guest system to your applications menu, to save you from creating your own desktop entry file as you have done here.

to ensure they appear on the application menu?

Exported files and generated entries aught be displayed in app menu's currently, if they don't in your case for whatever reason then this should be raised as a separate issue and an error. This isn't the purpose behind my suggestion, which is a better means of managing exported files from a developers perspective, making cleaning up exports easier, thereby not cluttering up default locations.

[89luca89]

I was thinking @codexMechanicus
a middle-of the ground solution, could be using symlinks

I'll export stuff into (for example) ~/.local/share/distrobox/applications/$CONTAINER_NAME
Then link the bin and desktop file, to the canonical paths

On removal of the container, simply remove the $CONTAINER_NAME directory, and remove broken links into the canonical paths bin and applications 🤔

[luc14n0]

@luc14n0 You can use the new command distrobox generate-entry to add a guest system to your applications menu, to save you from creating your own desktop entry file as you have done here.

to ensure they appear on the application menu?

Exported files and generated entries aught be displayed in app menu's currently, if they don't in your case for whatever reason then this should be raised as a separate issue and an error. This isn't the purpose behind my suggestion, which is a better means of managing exported files from a developers perspective, making cleaning up exports easier, thereby not cluttering up default locations.

I was just giving a silly bad example. My main point was that for a standard location to place .desktop files $XDG_DATA_HOME/applications is an option, in rootless setups, instead of using XDG_DATA_DIRS.

[89luca89]

@luc14n0 You can use the new command distrobox generate-entry to add a guest system to your applications menu, to save you from creating your own desktop entry file as you have done here.

to ensure they appear on the application menu?

Exported files and generated entries aught be displayed in app menu's currently, if they don't in your case for whatever reason then this should be raised as a separate issue and an error. This isn't the purpose behind my suggestion, which is a better means of managing exported files from a developers perspective, making cleaning up exports easier, thereby not cluttering up default locations.

I was just giving a silly bad example. My main point was that for a standard location to place .desktop files $XDG_DATA_HOME/applications is an option, in rootless setups, instead of using XDG_DATA_DIRS.

that's what it is already done, they are exported in $HOME/.local/share/applications

The idea was to have somewhat a dedicated directory in order to not litter the $XDG_DATA_HOME/applications, and have an easier way to cleanup when we remove a distrobox for example