Toolbox: Desktop files integration

Created on 21 Apr 2020  ·  18Comments  ·  Source: containers/toolbox

If you install an GUI App (for example VS Code, GNOME Builder, et cetera), it will create desktop file in /usr/share/applications. But toolbox have isolated system (except homedir) and it will not bind.
If there can be an option to create desktop file from it like:
$ toolbox desktop code.desktop will do:

  1. Copy /usr/share/applications/code.desktop to .local/share/applications/toolbox_code.desktop
  2. Change all executable references (/usr/bin/code or code) to the conainers (/usr/bin/code -> toolbox run /usr/bin/code et cetera)
  3. Copy icon to local icon storage

Also add option to remove:
$ toolbox desktop code.desktop -r
to remove ~/.local/share/applications/toolbox_code.desktop and the icon

1. Feature request 5. Good First Issue 5. Help Wanted

Most helpful comment

I'm GOing for it!

All 18 comments

Hi @oksoft-git! This looks interesting. I was thinking of providing something similar to this. Would you want to make a PR with this feature (but not in Shell but in Go for the new version of Toolbox?

@debarshiray, what do you think?

I'm GOing for it!

This feature would greatly benefit silverblue users cause then you can easily use applications from the container

Would it be possible to include basic binary integration, to allow it to export basic command wrappers to the base system or is that out of the scope for the project?

As command wrappers i mean wrapper like this for nano for example (it may be more complex than this for some programs)

!/bin/bash
toolbox nano "$@"

(flatpak does something like this, could look into it further)

Hi @sandorex ! The feature you are talking about is already being tracked here: #145. It is one of the priorities after rolling out the updated Toolbox. While these two features are a similar, the solution to them is very different.

I'm wondering now if giving Toolbox the power to create/edit .desktop files for apps is really the way to go. It would require Toolbox to know where to locate the existing .desktop file, find the right lines, update them and move/copy the file to a location where the desktop (not everybody uses GNOME Shell) will find it and use it. This seems to me as unnecessarily big chunk of logic that wouldn't come to much use.

Instead section in the documentation with instructions how to update an existing .desktop file sounds better to me.

If I'm wrong about the complexity, then, please, prove me wrong.

I may be wrong but desktop files are searched recursively in ~/.local/share/applications so a directory that contains only desktop files from toolbox (per container) and then just remove the desktop files that dont exist in the container but the modification i cannot really simplify

Second approach would be to give this responsibility to another application (toolbox-desktop-integration) which would allow selection of desktop files to bring to the host (putting them in their folders would be smart, like ~/.local/share/applications/_toolbox_XXX where XXX is the container name)

Interested in your opinion @HarryMichal

It is almost done, but I cannot extract icon path from desktop file to copy to host.

_edit_: Creating dedicated tool for it will be better. I will recreate it.

@ondra05 Great work!

There's one thing that i personally would improved (it's not necessary though) and that is using cat to read the file from the container, it will work fine but its kinda hacky, cause podman shares images with toolbox you can use podman cp to copy files between container and the host

I been toying with this idea in this python script. Currently it install desktop files, icons, mime and metainfo. I have yet to add a uninstall feature, but doesn't seem too hard.

I sadly dont have the time to do a proper app, i've made the UI but GTK is just pain in the ass, ill probably do CLI only app someday (hopefully)

I sadly dont have the time to do a proper app

I think that a GUI for this is overkill. Imho this should be handled with commands in the direction of toolbox export with flags as --remove and --list.

I will try to look into it. I wonder if it is possible to just add a toolbox export APP command that calls, say, this python script inside the toolbox in a similar fashion to toolbox run export.py ARGS. While it is clearly better to do it in go, this only involves copying files from toolbox's /usr to $XDG_DATA_DIR and it might be simpler to use a script for it. I don't know what the maintainer this of this possibility.

Note that such extension would have to take many things into account, the problem of handling icons is non-trivial for example.

This is similar to the discussion around the addition of the run command, including this IRC conversation from #silverblue on Freenode:

From #silverblue on Freenode:

15:56 <rishi> otaylor: alexlarsson: Hey! Do you have any thoughts on            
      https://github.com/debarshiray/toolbox/pull/76 ?
15:57 <rishi> In short, people want to be able to do "toolbox run emacs".
15:57 <rishi> And I am worried about encroaching on Flatpak territory.
15:58 <alexlarsson> I don't think its a huge problem.
15:58 <otaylor> rishi: I suspect we need such functionality if we want the      
      toolbox to be a serious tool that people rely on
15:58 <alexlarsson> No 2 tools will be 100% non-overlapping
15:59 <alexlarsson> and i can imagine using this in non-flatpak like way
15:59 <alexlarsson> toolbox run some-service
15:59 <otaylor> rishi: I'd be more worried about adding, say, menu item         
      management so that it looks like 'toolbox run emacs' is a real app
16:00 <alexlarsson> I mean, some people use flatpak for cli stuff
16:00 <rishi> otaylor: alexlarsson: Okay!
16:00 <alexlarsson> which is not quite the point
16:00 <alexlarsson> Still, it works
16:01 <alexlarsson> The main thing is that the design decisions that drive      
      toolbox and flatpak are driven by a particular usecase
16:01 <alexlarsson> Not that they can't be used other ways
16:03 <rishi> Yeah, toolbox is very clearly: "use jhbuild on Silverblue".
16:04 <rishi> walters would say "separate development prefix", but that's       
      about it, I think.

It's already possible to add toolbox run emacs in the .desktop file for the application installed inside the container. Having a command that actually parses and creates .desktop files is another step in that same direction, and I am not sure if it's one step too far.

@debarshiray what do you think of a python script that copies desktop files, icondata and metadata? I already made one and it is working just fine.

It's definitely one way to go about it. However, I am hesitant to include it in Toolbox right now.

I am interested in working on this issue !

...
not everybody uses GNOME Shell
...
If I'm wrong about the complexity, then, please, prove me wrong.

@HarryMichal I believe your concerns are unnecessary.
Nowadays .desktop files and icon file themes are designed to be desktop-agnostic and subjected to XDG Specs:
https://specifications.freedesktop.org/
https://specifications.freedesktop.org/desktop-entry-spec/latest/index.html
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

To all:
can we design needed functionality as DNF plugin maybe?

PS: just realized Flatpak exposes apps already so we could just borrow it's code if needed.

I have yet to add a uninstall feature, but doesn't seem too hard.

Thanks @A6GibKm, please do! :)

Was this page helpful?
0 / 5 - 0 ratings