[Suggestion] Some more options for distrobox-export: --hide-app, --app-path, --force, perhaps even an auto-export?

Hi all some of these suggestions are a bit niche but others not so much.

distrobox-export --hide-app The first suggestion --hide-app sets the Hidden tag to Hidden=true if the tag present and adds the line if it's not.

Reason: some user may not want an export to clutter their menu's yet may want it in the /usr/share/applications folder

-ha | --hide-app)
    hide=1
    shift
    ;;

options --force/ -f: force export while app is not installed (eg. during installation) --hide-app/-ha: hide exported apps from the desktop menu's
if [ "${hide}" -eq 0 ]; then container_command_prefix="${DISTROBOX_ENTER_PATH:-"distrobox-enter"} -T -n ${container_name} -- \"${is_sudo} " else container_command_prefix="Hidden=true \n ${DISTROBOX_ENTER_PATH:-"distrobox-enter"} -T -n ${container_name} -- \"${is_sudo} " fi

I implemented it this way (there is no check for Hidden=* already being present in so watch out for that!)

distrobox-export --export-path/--app-path Allow a custom path for a .desktop file, in-case users just want them to be on their desktop or launch from a folder. Adapting --export-path to work with scripts besides binaries is probably the best way to implement this.

distrobox-enter --auto-export I suppose a bash watchdog running in the guest that auto-exports might be something that other users might want? One way for this to work is to cache the files in a home folder and allow the user to decide which to export. In the end I decided it was best to keep my export scripts in python (mostly) as I'm new to bash scripting, I'll release these soon.

Thanks for reading, I hope some of these suggestions are useful!

Hello, I'd just like to contribute with my opinions here:

distrobox-export --hide-app The first suggestion --hide-app sets the Hidden tag to Hidden=true if the tag present and adds the line if it's not.

That sounds like a reasonable option to me; if the feature is there, then we should definitely be able to use it :+1:

if [ "${hide}" -eq 0 ]; then container_command_prefix="${DISTROBOX_ENTER_PATH:-"distrobox-enter"} -T -n ${container_name} -- \"${is_sudo} " else container_command_prefix="Hidden=true \n ${DISTROBOX_ENTER_PATH:-"distrobox-enter"} -T -n ${container_name} -- \"${is_sudo} " fi

This implementation is a bit "hacky", so to speak, because the container command prefix variable has a very specific purpose; however, it should still be possible to implement this feature without much hassle

distrobox-export --export-path/--app-path Allow a custom path for a .desktop file, in-case users just want them to be on their desktop or launch from a folder. Adapting --export-path to work with scripts besides binaries is probably the best way to implement this.

Seems perfectly reasonable to me as well :+1:

Edit: The only caveat would be that, to use the -d (delete) feature of distrobox-export, the user would need to specify the exact same --export-path again, but I believe that is already the case for binary exports, so shouldn't be an issue

distrobox-export --force Getting more niche --force forces the export even if the app is not detected on the host OS. Which happens if the application isn't installed yet, perhaps the best solution isn't to brute force the export but wait until the installation is finished? Since when I tried to implement this it exported empty files. This happened as I was trying to have applications auto-export.

I believe this would be quite hard to implement actually, because - at least from what I've understood - the current implementation depends on exporting the apps' own .desktop files. It could be possible, however, to defer the export to until the app is installed, but I'm not sure if this would be at all practical to implement (after all, if it's not installed yet, then it could also never actually get installed!). So, I believe there are several obstacles to the implementation of this feature and, being honest, not much practical use, but if you thought of something to address those concerns, make sure to share

distrobox-enter --auto-export I suppose a bash watchdog running in the guest that auto-exports might be something that other users might want? One way for this to work is to cache the files in a home folder and allow the user to decide which to export. In the end I decided it was best to keep my export scripts in python (mostly) as I'm new to bash scripting, I'll release these soon.

This doesn't sound like a bad idea at all, but the implementation surely will have to be carefully thought out Perhaps a cron job or something like that? Not sure how feasible this would be But an interesting suggestion nonetheless

Hi thanks for the contribution.

from what I've understood - the current implementation depends on exporting the apps' own .desktop files.

Looking at the source code you are right, the only check is if the .desktop file exists, for some silly reason I thought the check was to see if the executable is present in order to ensure the export was actually usable. So it already behaves as I wanted it to under the flag.

The reason my .desktop file was missing is as the name was changed during installation. I'd say this is best addressed on the watchdog end and I need to implement my own checks and wait until the app is fully installed and not force it. So the complete opposite of what I was trying to do?

Perhaps a cron job or something like that? Not sure how feasible this would be But an interesting suggestion nonetheless

A cursory search suggests that cron, watch could do the job but inotify seems the most similar tool to the watchdog module I'm currently using. I think it would be very possible with inotify. https://www.man7.org/linux/man-pages/man7/inotify.7.html

Hi @s2live @PgBiel

a couple of thoughts on the thing :smile:

Exporting an app that is not installed

this is not possible, I'm not "generating" a desktop file, I just modify an existing one, so if the file is not there there is not much I can do

Hidden flag

What's the point of having an exported app but not in the menu? We're talking either: 1 - graphical apps that are launched from the menu 2 - graphical apps that are launched by file association This last category many times has the Hidden=true already, so I'd stick to whatever the developer thought for their apps

If you need to export an app and you don't want it in the menu, just to be launched from CLI, it's better to export the --bin

Whatchdog Export

I thought of it, but starts to become a bit too complicated, and also a bit out of scope. Exporting should not be automatic And this would only amplify the issue #301

Hi Luca :)

I thought of it, but starts to become a bit too complicated, and also a bit out of scope.

I think this is as you say out of distrobox's scope and if people desire that it's best to look to a third party tool.

Exporting should not be automatic

Perhaps not not on distrobox, put perhaps using third party tools

And this would only amplify the issue #301

I'd argue one of those possibilities is that this can actually be part of a solution to issue #301 (Clean up exported apps). Since if the guest .desktop dir is checked or monitored when then the removal of a .destop file from the host can be detected just as an addition can. The same monitoring process process for triggering auto-exports can trigger a auto-remove function. tldr; the host system would only contain .desktop files still on the guest. @PgBiel Suggested a log file if the log file contained the guests GUID and those GUID's were included in the .desktop filename a distrobox-rm command could put those files in the users waste basket. The python script I have detects any change to a .desktop file in the guest folder, create, read, updates, deletes etc, I could work on a bash one at some point.

What's the point of having an exported app but not in the menu?

I understand if it's a bit to niche to implement but it make does a lot more sense if an auto-exporter is being used. As well as a third party menu to display distrobox guest apps as I've developed and am almost ready to release, but I thought others might like this too. I never did get packageKit working so I forked pacmanGUI, to provide a GUI wrapper for guest CLI package managers.

Maybe best to handle all of this of this at my end, I already have the scripts to edit the .desktop files, but I wanted to just use the export command if possible. My app will provide users the option to un-hide apps to have them show up in their host folder, so I will be editing this field in any case.

Perhaps not not on distrobox, put perhaps using third party tools

Yea exactly, you can create scripts/programs that use distrobox-export inside a container to do that for sure :+1:

I'd argue one of those possibilities is that this can actually be part of a solution to issue https://github.com/89luca89/distrobox/issues/301 (Clean up exported apps). Since if the guest .desktop dir is checked or monitored when then the removal of a .destop file from the host can be detected just as an addition can. The same monitoring process process for triggering auto-exports can trigger a auto-remove function. tldr; the host system would only contain .desktop files still on the guest. @PgBiel Suggested a log file if the log file contained the guests GUID and those GUID's were included in the .desktop filename a distrobox-rm command could put those files in the users waste basket. The python script I have detects any change to a .desktop file in the guest folder, create, read, updates, deletes etc, I could work on a bash one at some point.

I'd like to maintain it as "stateless" as possible, so maybe I'll do some sort of distrobox-export --delete-all to be called when a distrobox rm is called :shrug:

Maybe best to handle all of this of this at my end, I already have the scripts to edit the .desktop files, but I wanted to just use the export command if possible. My app will provide users the option to un-hide apps to have them show up in their host folder, so I will be editing this field in any case.

That's a really neat project I'm looking forward to it :smile: But yea probably that's more on your side than distrobox's side, adding/removing Hidden=True from existing files should be quite easy on your side, without having to completely manage the desktop file yourself

I'd like to maintain it as "stateless" as possible, so maybe I'll do some sort of distrobox-export --delete-all to be called when a distrobox rm is called

That's a neat solution, much better than storing state.

That's a really neat project I'm looking forward to it

Thanks! :) I guess the issue can be closed as we've covered everything.

As well as a third party menu to display distrobox guest apps as I've developed and am almost ready to release, but I thought others might like this too. I never did get packageKit working so I forked pacmanGUI, to provide a GUI wrapper for guest CLI package managers.

Oh hey, that's pretty cool @s2live ! I've also been working on a GUI app interfacing with distrobox, but more on the management sense (to manage containers, but maybe also - eventually - exported apps and packages and the like), mostly to practice GTK 4, but also because I believe that GUI apps like this would definitely increase overall adoption for distrobox across the userbase haha

Please make sure to tell when your app is released to the public. It'd be awesome to share experiences, and possibly contribute to its development :eyes:

I've also been working on a GUI app interfacing with distrobox, but more on the management sense (to manage containers, but maybe also - eventually - exported apps and packages and the like

Nice @PgBiel! My app doesn't do a huge amount of interfacing with distrobox or distro management just a basic set up, but it presents an app launcher menu as you can see. It also provides a GUI for apps to get packages from host repositories which I'm really happy with, I struggled trying to get third party applications working but they ran into fatal issues.

I believe that GUI apps like this would definitely increase overall adoption for distrobox across the userbase

That was my motivation, I wanted be a simple cross-distro tool. Is your application in python too?

Nice @PgBiel! My app doesn't do a huge amount of interfacing with distrobox or distro management just a basic set up, but it presents an app launcher menu as you can see. It also provides a GUI for apps to get packages from host repositories which I'm really happy with, I struggled trying to get third party applications working but they ran into fatal issues.

That sounds really interesting actually @s2live! Please keep me posted on your progress! Perhaps we could collaborate in the future, when our projects mature :eyes: In my view, the distrobox project as a whole will definitely benefit from all this work!

That was my motivation, I wanted be a simple cross-distro tool.

Yes, the good thing about using the GTK stack is that it is compatible (or, otherwise, easy to setup) with most, if not all, distros, just like distrobox attempts to do. So, I believe we are definitely heading the right way here.

Is your application in python too?

Yup! While I did consider writing it in e.g. C or Rust in order to sharpen my knowledge of those languages, I found that using Python (a language I know well) would simply make the project more manageable and easier to work with. Besides, it would likely foster further collaboration from the community (if it so desires). Overall, I found it a great choice for the project. The same will probably apply to yours!

Please keep me posted on your progress!

@PgBiel Well I'm close to 1.0! I've tested the launcher in pytest and it all looks good. I've now got a GUI install process working for pacman and ubuntu apt, with the hard parts done for debian apt, fedora dnf and zypper. The GUI installer allows user to search and displays icons for packages though many are blank as either the icon cannot be found using the package name alone, or aren't supplied by papirus, I would like better icon support. The installer appears in the launcher menu as a guest application, but it is the same script just running in a guest container.

Python was great no issues there, I don't have much experience with it but in the past nearly everything I try has always just worked with it, and the same applies here. :) I also considered C, and like you am glad I didn't. Though I found myself doing more and more in shell scripts as the project went on, no fault of pythons just that all those modules do is shell. GTK was probably the best option for compatibility, but honestly I hated using it. Maybe I made a mistake using glade? Making GUI's in a GUI like that is more what I'm used to and I found making more complex issues a chore without it so I went that way. Then I found making things dynamically on top of glade painful. Oh and then there's the fact that iconView doesn't natively support right-clicking icons or selection input besides left clicking, all I want is a context menu and some dynamic buttons. Maybe I'm the problem here but I've never had so much hassle with a GUI toolkit honestly. How did you find using GTK? If I were to do it again I might use tkinter as it was just a proof of concept and I certainly didn't make the most of GTK's potential.

The installer is basic but it's advantage is it's simplicity! Because it only carries out the basic tasks of updating, installing and removing packages, not much changes are needed to set it up for it for each distro. The "hard part" isn't really that hard it's just transforming the different search results of each client into a bash array of package names. What I want to do soon is have the commands for instructions and formatting feedback in one config file, so that profiles can easily be created for each distro's package manager. It would be nice to have a profile for all the distros that distrobox officially supports. That's the downside of the approach but nothing else worked. Moving on down the line I want to look at how nala does it's thing to actually improve upon apt and make it more rubust, and stable and set up faster mirrors then implement similar. I think my focus is gonna be more on the installer end. As for better icon support most repos don't provide information that I could use to make a better filler for absent icons than the present transparent image. I can't think if another way to solve this than mining data to build a database that links the info in a packages .desktop file to package names? As I've been unable to find an existing source with this info all one place and readily accessible, but maybe there is a good reason that doesn't exist?

I would be interested in hearing more about your app, does it have a name? If not does distroman sound good? Does it basically do what distrobox does, but GUI? I would be up for collaborating sure, :smile: it would be good to share ideas and perhaps maintain compatibility? Also I can recommend your app for users that desire a more in-depth configuration. :)

@PgBiel Well I'm close to 1.0! I've tested the launcher in pytest and it all looks good. I've now got a GUI install process working for pacman and ubuntu apt, with the hard parts done for debian apt, fedora dnf and zypper.

That is very nice to hear!

The GUI installer allows user to search and displays icons for packages though many are blank as either the icon cannot be found using the package name alone, or aren't supplied by papirus, I would like better icon support. The installer appears in the launcher menu as a guest application, but it is the same script just running in a guest container.

Yeah, to be honest, icons are some of the largest pains I face when working in containers. I usually see myself doing tons of symlinks from host to container just for some basic icons to show up.

You should probably research directories under /usr/share/icons, $HOME/.local/share/icons and ~/.icons, that should definitely be a start. Most app icons I find have their icons in .svg format for most themes I've checked, so keep that in mind. Either way, this will probably take a bit of time to figure out entirely.

Python was great no issues there, I don't have much experience with it but in the past nearly everything I try has always just worked with it, and the same applies here. :) I also considered C, and like you am glad I didn't. Though I found myself doing more and more in shell scripts as the project went on, no fault of pythons just that all those modules do is shell.

Yup. I'm also running several shell commands from within python. Since distrobox is based on shell, I guess there's no choice here :p

GTK was probably the best option for compatibility, but honestly I hated using it. Maybe I made a mistake using glade? Making GUI's in a GUI like that is more what I'm used to and I found making more complex issues a chore without it so I went that way. Then I found making things dynamically on top of glade painful.

Oh yeah, Glade doesn't even work for GTK 4 so... I do all the UI by hand lol (in xml). I find it better because it gives me a chance to learn, and also forces me to avoid making the UI too messy or complex. There is an experimental graphical UI editor for GTK 4 out there (forgot its name now), but, for now, this is working out for me.

Oh and then there's the fact that iconView doesn't natively support right-clicking icons or selection input besides left clicking, all I want is a context menu and some dynamic buttons. Maybe I'm the problem here but I've never had so much hassle with a GUI toolkit honestly. How did you find using GTK? If I were to do it again I might use tkinter as it was just a proof of concept and I certainly didn't make the most of GTK's potential.

Well, GTK does have some annoyances, that is correct. There's also the fact that autocompletion is kind of a pain to get to work for PyGObject, and documentation for GTK 4 in Python is very scarce. However, so far, I've been liking how things turn out.

However, it's worth saying that, if GTK doesn't work out for you, then you might want to try out PyQt5 (or PyQt6) - I've used PyQt in the past for a simple app designed to be compatible with Mac and Windows (I didn't use Linux at the time), and it went quite smoothly (and its graphical UI designer works fantastically, and even generates lots of python code for you). My aim with using GTK is mostly to learn it, as it's quite important for the Linux ecosystem (and more broadly compatible between distros), but Qt (and PyQt) is a great choice here as well. Worth giving it a shot at some point.

The installer is basic but it's advantage is it's simplicity! Because it only carries out the basic tasks of updating, installing and removing packages, not much changes are needed to set it up for it for each distro. The "hard part" isn't really that hard it's just transforming the different search results of each client into a bash array of package names. What I want to do soon is have the commands for instructions and formatting feedback in one config file, so that profiles can easily be created for each distro's package manager. It would be nice to have a profile for all the distros that distrobox officially supports. That's the downside of the approach but nothing else worked. Moving on down the line I want to look at how nala does it's thing to actually improve upon apt and make it more rubust, and stable and set up faster mirrors then implement similar. I think my focus is gonna be more on the installer end.

I think it's definitely important to research good solutions here in terms of package managing across different distros. I did consider that I could eventually face those issues as well. Feel free to share your progress in this matter, if you do advance here.

As for better icon support most repos don't provide information that I could use to make a better filler for absent icons than the present transparent image. I can't think if another way to solve this than mining data to build a database that links the info in a packages .desktop file to package names? As I've been unable to find an existing source with this info all one place and readily accessible, but maybe there is a good reason that doesn't exist?

I'm not very qualified to respond to these questions at the moment, but you'll likely need to dig deep into the icon directories I mentioned at the beginning of this response. And I can give you a good starting point - in my system, at least, a good chunk of apps' icons are present in /usr/share/icons/hicolor/scalable/apps. Make sure to take a look!

I would be interested in hearing more about your app, does it have a name? If not does distroman sound good?

Well, I was actually thinking about the name part... at first I was just naming it Distrobox GUI, but something more unique would probably be better. distroman doesn't sound that bad, actually - maybe I'll use something like that. I'll keep you in touch.

Does it basically do what distrobox does, but GUI?

Yes, it's basically a GUI wrapper around distrobox's commands. It'd list the containers and then allow you to perform existing actions on them.

However, it's worth saying that it's very early yet and, well, I have been struggling to find time to fully commit to this project... either way, I'm slowly getting there. I hope to be able to present a working alpha version soon.

I would be up for collaborating sure, smile it would be good to share ideas and perhaps maintain compatibility?

Yes! Let's stay in touch - our projects have great potential, I think. :+1:

Also I can recommend your app for users that desire a more in-depth configuration. :)

Haha, perhaps? But please wait until I have a working version first hehe :stuck_out_tongue_winking_eye:

I think it's definitely important to research good solutions here in terms of package managing across different distros. I did consider that I could eventually face those issues as well. Feel free to share your progress in this matter, if you do advance here.

The holy grail there is getting packageKitD to work inside a container, pacakgeKit is an abstraction layer between user interfaces and a systems package manager. The issue is it relies on the systemD and Dbus which isn't on the container but on the host. You can actually view and install apps when running gnome-software from a guest, you are using the host package management system not the guests. One possible fix is make the reverse happen run GUI software centre on the host that communicates with an instance of packageKit and systemD in an init container. That should get around the fact init systems run cant access the hosts display. The other option is to somehow allow the GUI to run on the guest but use an instance of packageKit on the host and the hosts systemD and Dbus but have them communicate with the guests package management system not the hosts. Or you can do what I did and give up after spending way too long trying...

For now I'm using a simple tool that so far takes only a few mins to adapt to a different system, but as APT warns thier CLI's don't offer a stable interface..

a good chunk of apps' icons are present in /usr/share/icons/hicolor/scalable/apps. Make sure to take a look!

Hicolor could be a good way to go. To state it more clearly than I did before there were two different issues, so the task here is to view the icon of a file that is not yet installed on a system, these are the search results from a guests CLI package manager. The main issue really is that some packages just don't have icons, they aren't supposed to have icons as many are not apps. Icon themes themselves are a good example, as well as plugins and files etc. These packages ideally need a place holder, but package metadata contains information relevant to package managment. Before installation there isn't any data that helps when displaying apps or categorising them like the tags in .desktop files do. What I would like to do is display an icon representing the category of a package, I'm going to have to look into how other GUI's front ends achieve this, though I think many just stick in an icon for a .deb/.rpm etc which isn't what I want.

For now I'm using a simple tool that so far takes only a few mins to adapt to a different system, but as APT warns thier CLI's don't offer a stable interface..

Ah, I see. Regarding using PackageKit, have you tried doing the symlinking stuff (as suggested here, under "Running Latest GNOME": https://github.com/89luca89/distrobox/blob/main/docs/posts/run_latest_gnome_kde_on_distrobox.md) to be able to have some sorta-working systemd and dbus? I mean, this probably won't work, at least not fully (I have had many issues with this on the past, on my OpenSUSE Tumbleweed machine), but anyway, that's probably what I'd try at least. If that doesn't work then... well, I guess there isn't much that can be done here. I wonder if this would work with containers created with the --init flag?

Anyway, but, for now, yeah, you'd probably have to create separate definitions for each package manager, which can sure be annoying at times.

To state it more clearly than I did before there were two different issues, so the task here is to view the icon of a file that is not yet installed on a system, these are the search results from a guests CLI package manager.

Ahhh I see what you mean, I thought were you talking about installed packages. Then yeah, it's... more complicated. Perhaps you can research how Discover, from KDE Plasma, does it, but even then I doubt it would work for every package. Honestly, I think this will be hard to solve, as most packages available don't actually associate themselves with any icon in particular; it's not a requirement, at least. But seeing how other frontends do it should give you a clue at least for some packages.

By the way, we should probably attempt to move further conversation elsewhere, as I believe we might be cluttering this space (sorry to anyone who is getting pinged hahaha)... If you have a matrix account, or maybe Discord or something like that, do tell me if you'd like to, perhaps, exchange further messages there.

Ahh I hoped people wouldn't be pinged unless mentioned now the issue is closed. Sorry all!

Since I've gone public I've moved the conversation to here! https://github.com/codexMechanicus/AppBox/issues/1

89luca89 / distrobox

[Suggestion] Some more options for distrobox-export: --hide-app, --app-path, --force, perhaps even an auto-export? #345