Automatically add .desktop files in toolbox to the host

[ghost]

Is your feature request related to a problem? Please describe.
I use Fedora Silverblue and I use a separate toolbox for development. I installed my IDE in the toolbox, but since toolbox doesn't automatically add desktop entries, I had to manually make one.

Describe the solution you'd like
Automatically add .desktop files made in toolboxes to the hosts $HOME/.local/share/applications/

Describe alternatives you've considered
Manually writing a desktop file is tedious and not exactly a smooth experience.

Additional context
Nil

[akdev1l]

I've tried to implement this feature. It is not terribly difficult but I think it requires that we keep a record exported desktop files and their respective toolboxes. We need to be able to remove the exported applications when we do toolbox rm myapp.

My idea is what we essentially follow the approach taken by distrobox. I propose the following CLI

# export firefox from "mytoolbox"
toolbox export --container mytoolbox  --app /usr/share/application/firefox.desktop
# export ripgrep from "mytoolbox"
toolbox export --container mytoolbox --bin /usr/bin/rg
# export nginx from "mytoolbox"
toolbox export --container mytoolbox --service nginx
# remove ripgrep import
toolbox export --clean rg
# removing the toolbox cleans up all the imported applications and binaries
toolbox rm mytoolbox

to enable this we should keep a database mapping the toolbox containers to the exported applications, I suggest the following scheme (I was planning on keeping this on a JSON file but it doesn't have to be).

{
  "toolboxes": [
      {
        "container": "mytoolbox",
          "exported": {
            "bin": [
              { "containerPath": "/usr/share/applications/firefox.desktop", "hostPath": "/home/akdev/.local/share/applications/firefox.desktop" }
            ],
            "app": [
              { "containerPath": "/usr/bin/rg", "hostPath": "/home/akdev/.local/bin/rg" }
            ],
            "service": [
               { "containerPath": "/usr/lib/systemd/system/nginx.service", "hostPath": "/home/akdev/.local/systemd/nginx.service" }
            ]
          }
      }
  ]
}

in this data structure we keep track of the applications we have exported per container so we can quickly clean up on toolbox rm mytoolbox. To achieve this we would have to do some changes:

1. toolbox enter - it will need to create and initialize the database if it doesn't exist and if it exists it would append a new object to the "toolboxes" array.
   2., toolbox rm - it will need to remove the container from the "toolboxes" array and make sure to clean up all the exported applications
2. toolbox export - subcommand needs to be created with three modes of operation:
   a. --application - takes an argument that could be either a path to a .desktop file within the container or an application name as stated in the .desktop file. If a path is provided we will export it as is (perhaps after checking it is not a binary). If an application name is provided then we should grep for all the desktop files in the default location /usr/share/applications and find their ApplicationName and export if we find a single exact match.
   b. --bin - takes an argument that is a full path to an executable on the host. It will simply validate that the file is indeed executable and export it as is into the toolbox database.
   c. --service - takes an argument which should be a systemd service unit name or an absolute path inside the container pointing to a systemd service unit. If a path is provided we should validate that it is a valid systemd unit file and we should then export the path as is onto the user's systemd user session on the host. If a unit name is provided then we should find the file in /usr/lib/systemd/system and /etc/systemd/system and we need to run systemctl is-valid on them before exporting - if all this is successful we export the path onto the host.
   c. --clean - takes an argument which is either an exported application name, command name or service unit name (firefox or rg) and it will find matching exports in the database and remove the export from the host.

I think this is one of the most requested features and reasons why people use distrobox as well as home isolation so it would be good to get this going. I have a rough implementation of the toolbox export -c mytoolbox --bin command so we can see how this may look from a CLI perspective:

$ ./toolbox export --help
Exports an application, binary or service to the host

Usage:
  toolbox export [flags]

Flags:
  -a, --app string           application to export
  -b, --bin string           path to binary to export
  -c, --container string     container name
  -d, --delete               Set this flag to export a command line application
  -p, --export-path string   Path to export binary applications (default "$HOME/.local/bin")
  -e, --extra-flags string   Set this option to pass extra flags to the application
  -h, --help                 help for export
  -s, --service string       systemd service name to export

Global Flags:
  -y, --assumeyes          Automatically answer yes for all questions
      --log-level string   Log messages at the specified level: trace, debug, info, warn, error, fatal or panic (default "info")
      --log-podman         Show the log output of Podman. The log level is handled by the log-level option
  -v, --verbose count      Set log-level to 'debug'

[glidingthrough]

@akdev1l can you please let us know if there's been any progress in implementing this? This export feature, alongside the ability to update all containers with one command in distrobox, is what has me thinking of layering it in to the base image. It would be great if this was natively supported in toolbox so we don't go bloating our installations unnecessarily.

[Docmine17]

It would be really good to have a feature like this in toolbx. please 🫶👍