Flatpak is made to run desktop apps, and there are apps like KDE Discover or GNOME Software that let you manage the Flatpak installations on your system.
Of course, we still need a way to handle Flatpak from the commandline. The flatpak commandline tool in 1.0 is powerful without being overwhelming (like git) and way friendlier than some other tools (for example, ostree).
But we can always do better. For Flatpak 1.2, we’ve gone back to the drawing board and did some designs for the commandline user experience (yes, that needs design too).
Many Flatpak commands produce information in tabular form. You can list remotes, apps, documents, etc. And all these have a bunch information that can be displayed. It can be overwhelming when you only need a particular piece of information (and overflowing the available space in a terminal).
To help with that, we’ve introduced a –columns option which you select which information you want to see.
You can explore the available columns using –columns=help. In Flatpak 1.2, all the list-producing commands will support the –columns option: list, search, remotes, remote-ls, ps, history.
One nice side-effect of having –columns is that we can add more information to the output of these commands without overflowing the display, by adding optional columns that are not included in the default output.
It happens all the time, I want to type search, but my c key is sticky, and it comes out as searh. Flatpak used to react to unknown command by dumping out its –help option, which is long and a bit overwhelming.
Now we try to be more concise and more helpful at the same time, by making a guess at what was meant, and just pointing out the –help option.
In the same vein, the reverse-DNS style application ID that Flatpak relies on has been criticized as unwieldy and hard to handle. Nobody wants to type
flatpak install flathub org.gnome.meld
and commandline completion does not help too much if you have no idea what the application ID might be.
Thankfully, that is no longer necessary. With Flatpak 1.2, you can type
flatpak install meld
and Flatpak will ask you a few questions to confirm which remote to use and what exact application you meant. Much friendlier. This search also works for the uninstall command, and may be added to more commands in the future.
Flatpak repos contain appstream data describing the apps in detail. That is what e.g. GNOME Software uses on its detail page for an application.
So far, the Flatpak commandline has not used appstream data at all. But that is changing. In 1.2, a number of commands will show useful information from appstream data, such as the description shown here by the list and info commands:
If you pay close attention you may notice that column names can be abbreviated with –columns.
Here’s the commandline version of theming. We now set a custom prompt. to let you know what context you are in when using a shell in a flatpak sandbox.
You can customize the prompt using
flatpak override --env=PS1="..."
The application ID for the sandbox is available in the FLATPAK_ID environment variable.
The beast: Progress
Updates and installs can take a long time – there are possibly big downloads and there may be dependencies that need to be updated as well, etc. For a good user experience it is important to provide some feedback on the progress and the expected remaining time.
The Ostree library which Flatpak uses for downloads provides progress information, but it is very detailed and hard to digest. To make this even more challenging, there is not that much space in a terminal window to display all the relevant information.
For 1.2, we’ve come up with a combination of a table that gets updated to display overall status and a progress line for the current operation:
A similar, but simpler layout is used for uninstalls.
All of these improvements will appear in Flatpak 1.2, hopefully very soon after the New Year. Something to look forward to. 📦📦📦
5 thoughts on “Flatpak commandline design”
Why did you choose ‘domain.editor.software’? That is so ugly. editor.software would have been way more elegant and there is no case of two softwares with the same name and same editor but different organization so this is pointless. Your thoughts about that please?
The app id needs to be a valid bus name.
Awesome updates. Cant wait to see them in my distro.
Would be nice to see the uninstall indicate how much disk space was freed.
> no case of two softwares with the same name and same editor but different organization
You can’t guarantee that’s always going to be the case. By tying app IDs to domain names, you can guarantee uniqueness and there’s an already-available way of resolving disputes through ownership of the actual domain.
Comments are closed.