[Usability] Improve usability for users

[89luca89]

As stated out in this review: https://distrowatch.com/weekly.php?issue=20220221#distrobox

There are areas in which Distrobox can improve a lot in documentation, usability and discoverablity.

• Add a way to consult the compatibility table from distrobox itself
• Detect if we're running as sudo and point the user to the documentation if that's the case
• Improve the installer to create the dest_path if not exists
• Improve the installer informing the user to add dest_path to their $PATH
• Improve the error messages for missing container_manager and point out to the docs in case of missing one
• Improve the error messages in distrobox rm when container is running, suggesting the podman/docker command to run to stop it
• Add confirmation prompt to distrobox-rm, together with a --yes option
• Add distrobox stop to the list of commands
• Integrate host-exec in the container?

[misobarisic]

* Detect if we're running as sudo and point the user to the documentation if that's the case

* Improve the installer to create the `dest_path` if not exists

* Improve the installer informing the user to add `dest_path` to their $PATH

None of these points are distrobox related.

The problems they had with docker are not our fault. Familiarize yourself with docker. dest_path is not in $PATH. If you choose one that isn't in $PATH then, yeah, deal with it.

I am not really user friendly, am I?

[89luca89]

Ahahah I think it's just good to point them to the correct documentation
I see a lot of issues are opened for running distrobox as sudo, or using docker incorrectly so it doesn't hurt to add a couple of links in the docs (and man pages automatically)
For the installer just adding a it doesn't exist, should I create it? Y/n also doesn't hurt and helps a lot the user
For the $PATH we cannot do much, as adding a dir to a PATH is quite invasive, but printing a message to remind the user about it also it's just a quality of usage improvement that can also lower the number of bugs/issues opened for this stuff

[89luca89]

If there are other usability improvement proposals let's just comment here 👍

[nathanchance]

One suggestion I have for install would be requiring the installation prefix for -p, rather than the bin folder. This is more traditional (e.g. configure --prefix=... + make install). I know that I would personally be a little confused as a new user if I supplied -p $HOME/distrobox and ended up with $HOME/share because of the ../share for man_dest_path.

This would be a breaking change to install though so its use in packages would have to be audited. The AUR package would need to be updated at least, which is the only thing I surveyed.

[89luca89]

so to point out to (for example) ~/.local instead of ~/.local/bin?

Could be similar to what @misobarisic did in past, but should be superseded by the fact that now the -p argument is not needed, there are sensible default for bot root and rootless mode right?

[nathanchance]

so to point out to (for example) ~/.local instead of ~/.local/bin?

Correct.

Could be similar to what @misobarisic did in past, but should be superseded by the fact that now the -p argument is not needed, there are sensible default for bot root and rootless mode right?

Yes, those are sensible defaults. However, the code for -p is not overly complex so it is probably worth keeping around, as it is useful for people who like to customize exactly where their software is installed. For example, I use stow to manage locally installed versions of software, which I might do something like:

$ ./install -p $HOME/usr/stow/distrobox-1.2.13

$ ln -fnrsv $HOME/usr/stow/distrobox-1.2.13 $HOME/usr/stow/distrobox-latest

$ stow -d $HOME/usr/stow -R -v distrobox-latest
LINK: bin => stow/distrobox-latest/bin
LINK: share => stow/distrobox-latest/share

For the record, this is not my actual workflow, as I just run distrobox from a git checkout, but it illustrates how useful this could be.

[89luca89]

so to point out to (for example) ~/.local instead of ~/.local/bin?

Correct.

Could be similar to what @misobarisic did in past, but should be superseded by the fact that now the -p argument is not needed, there are sensible default for bot root and rootless mode right?

Yes, those are sensible defaults. However, the code for -p is not overly complex so it is probably worth keeping around, as it is useful for people who like to customize exactly where their software is installed. For example, I use stow to manage locally installed versions of software, which I might do something like:

$ ./install -p $HOME/usr/stow/distrobox-1.2.13

$ ln -fnrsv $HOME/usr/stow/distrobox-1.2.13 $HOME/usr/stow/distrobox-latest

$ stow -d $HOME/usr/stow -R -v distrobox-latest
LINK: bin => stow/distrobox-latest/bin
LINK: share => stow/distrobox-latest/share

For the record, this is not my actual workflow, as I just run distrobox from a git checkout, but it illustrates how useful this could be.

@nathanchance makes sense, but maybe it's better to open a separate issue for this as I see it not only is used by AUR, but also the snap and OpenSUSE's packages so maybe this will have to be a more tought and long lasting issue 😃

[codexMechanicus]

I have a suggestion that I think would improve usability.

I think the present behaviour where distrobox-create <new-image-name> upon entry creates a fedora-toolbox-35 image by default isn't the best behaviour. I believe it would be better to not accept input that doesn't explicitly define anything besides the images name.

My suggestion is that instead the user is asked to either define a source location or enter distrobox-create default <new-image-name> to pull fedora-toolbox-35 or something along those lines.

[misobarisic]

I have a suggestion that I think would improve usability.

I think the present behaviour where 'distrobox-create ' upon entry creates a fedora-toolbox-35 image by default isn't the best behaviour. I believe it would be better to not accept input that doesn't explicitly define anything besides the images name.

My suggestion is that instead the user is asked to either define a source location or enter 'distrobox-create default ' to pull fedora-toolbox-35 or something along those lines.

default would not work in use cases where default:latest image is present. This would introduce more confusion.

[codexMechanicus]

default would not work in use cases where default:latest image is present. This would introduce more confusion.

A more specific shorthand term like toolbox could work, if not removing the feature and keeping things explicit is more user friendly to me than anything potentially ambiguous.

[89luca89]

@s2live choosing fedora-toolbox as default, should be a sensible one as the image is curated for the use on Fedora Silverblue using the official tool toolbx, so It should always be an image ready to use

if this is not sensible enough, there could be two ways of handling this

• detect the host distro and try to default to that (but I think we're opening a pandora vase here 😃 )
• make it configurable, it still defaults to fedora-toolbox, but each distribution (via /etc) and user (in ~/.config?) can set it's own default for it

[codexMechanicus]

choosing fedora-toolbox as default, should be a sensible one

I agree that fedora-toolbox is the best thing to default to, if there must be a default. What I don't think is the best approach is having a command so flexible that it executes without any arguments. With the GUI app I am making one of my thoughts is "I better make it so the app cannot create default images as some side effect". Maybe I am being over cautious there? Not sure. 😅

[89luca89]

choosing fedora-toolbox as default, should be a sensible one

I agree that fedora-toolbox is the best thing to default to, if there must be a default. What I don't think is the best approach is having a command so flexible that it executes without any arguments. With the GUI app I am making one of my thoughts is "I better make it so the app cannot create default images as some side effect". Maybe I am being over cautious there? Not sure. sweat_smile

It's just following the toolbox behavior (both the fedora and the opensuse one) which have this "easy mode" where you just create and enter without specifying anything else.
It seemed to me to be quite sensible as the application works as intended and the user will be prompted (Y/n) for the download anyway

[codexMechanicus]

It seemed to me to be quite sensible as the application works as intended and the user will be prompted (Y/n) for the download anyway

They will be prompted if they don't have a local image already. Fair enough, since you mention it, it might be nice to implement a (y/n) prompt for the distrobox-rm command.

[misobarisic]

It seemed to me to be quite sensible as the application works as intended and the user will be prompted (Y/n) for the download anyway

They will be prompted if they don't have a local image already. Fair enough, since you mention it, it might be nice to implement a (y/n) prompt for the distrobox-rm command.

Podman/docker don't ask tor confirmation when removing containers. Why should this?

[89luca89]

it might be nice to implement a (y/n) prompt for the distrobox-rm command.

I like this 👍

EDIT: added to OP list

Podman/docker don't ask tor confirmation when removing containers. Why should this?

Contrary to pure podman, we're talking pet containers here, something you really care about, so it is in fact sensible to ask
(together with a -y option obviously)

[89luca89]

Implemented the distrobox-rm prompt 👍

[codexMechanicus]

Implemented the distrobox-rm prompt +1

Great to see this implemented! 😃

I have another suggestion, though there are many reasons for it to be objectionable, it might be out of scope, complex of simply undesired, but see what you think.

The current behaviour: By default while the guest cannot view the hosts .desktop application metadata, guest metadata can be viewed by the host in the default folder specified by xdg/freedesktop protocol (I believe this applies to pretty much every Linux DE, pretty much all of them at least semi-conform to xdg/freedesktop). This results in applications installed on containers being displayed in app menu's/finders etc and launched on the host.

Viewing and launching applications from the hosts menu is a nice feature however, unless I am mistaken there is presently no action taken to ensure that guest applications don't have conflicting dependencies with the host?

Applications could instead be executed in guest containers, even when triggered by action on the host, by modifying the .desktop files Exec= instruction, which could launch a script that checks if it's running on the host or in a container. If it's running on the host the script calls distrobox-enter and launches the application in the appropriate container. To do this I would set up a watchdog in the default .desktop dir. Upon modifying the .desktop file or on the first attempted launch from the host there could be another check as to whether there are any dependency conflicts between the application and the host, in which case the Exec= instruction is left unmodified.

This may be something more suitable to my GUI application built on distrobox but I'm gonna be working on it, so I thought I'd mention it as could be useful and desired by some on distrobox too.

[89luca89]

Viewing and launching applications from the hosts menu is a nice feature however, unless I am mistaken there is presently no action taken to ensure that guest applications don't have conflicting dependencies with the host?

Hi @s2live can you explain what you do mean? By design host and guest dependencies are completely separated

The current behaviour: By default while the guest cannot view the hosts .desktop application metadata, guest metadata can be viewed by the host in the default folder specified by xdg/freedesktop protocol (I believe this applies to pretty much every Linux DE, pretty much all of them at least semi-conform to xdg/freedesktop). This results in applications installed on containers being displayed in app menu's/finders etc and launched on the host.

This only applies to a common directory between host and guest, which will be only $HOME/.local/share/applications which is used only by distrobox export

Applications could instead be executed in guest containers, even when triggered by action on the host, by modifying the .desktop files Exec= instruction, which could launch a script that checks if it's running on the host or in a container. If it's running on the host the script calls distrobox-enter and launches the application in the appropriate container. To do this I would set up a watchdog in the default .desktop dir. Upon modifying the .desktop file or on the first attempted launch from the host there could be another check as to whether there are any dependency conflicts between the application and the host, in which case the Exec= instruction is left unmodified.

Not sure what you do mean with conflicting dependency, right now a desktop file is created only when the user actively uses distrobox export and apps exported this way are marked with a label (i.e. Gnome Photos (on fedora-toolbox-35)) so that you can export the same app from multiple distroboxes (eg. you need an older AND a newer version)

[codexMechanicus]

Hi @s2live can you explain what you do mean? By design host and guest dependencies are completely separated

What I mean is an application whose only dependencies are found on the host will be compatible, where-as one with dependencies that are not on the host will be incompatible. So an application that it is possible to run on the host.

right now a desktop file is created only when the user actively uses distrobox export and apps exported this way are marked with a label (i.e. Gnome Photos (on fedora-toolbox-35)) so that you can export the same app from multiple distroboxes (eg. you need an older AND a newer version)

Could there be an option for editing the exported file to open the desktop file so it is executed through a distrobox-enter command? Sorry, I should have investigated more thoroughly before commenting. [TLDR; this behavior is specific to my tinkering.] Hmm, yeah it looks like the behaviour I am observing is due to the way I have configured gnome-software and packagekit on the host and guest. I aught have guessed as it wasn't the behaviour one would expect to see. There were issues running packagekit on the guest, it seems that packagekit defaults to calling certain host services which cause confusion and render it and g-s unable to find repos or install files. However with packagekit on the host and not on the guest at least repo's are at least discoverable and installable and g-s identifies the files as RPM's when launched from a fedora guest, etc. It looks like things are actually worse than I thought as the .desktop files appear to only be installed upon the host, it's almost certain that the same is happening for all other files added when installed. 😬 I'm now thinking that unless I can implement a means to sandbox packagekit and g-s within a container completely separating them from the host my current approach is not going to work.

[89luca89]

Could there be an option for editing the exported file to open the desktop file so it is executed through a distrobox-enter command? Sorry, I should have investigated more thoroughly before commenting. [TLDR; this behavior is specific to my tinkering.]

Right now the export command picks the original desktop file and pre-pends distrobox enter [...] to the original command

I'm now thinking that unless I can implement a means to sandbox packagekit and g-s within a container completely separating them from the host my current approach is not going to work.

Probably some socket in /run/user? if you can pinpoint which socket packagekit and g-s uses we can create a init-hook for the create to isolate it, probably better to discuss this in a dedicated issue, here or in your project's bug tracker 👍

[codexMechanicus]

OK thanks so much for suggesting that solution Luca, I have made a specific thread here!