People often ask about the state of Flatpak in Discover, so today I’m going to write about that. Thew good news is that Discover’s Flatpak support is very good and getting better all the time. It’s fully production ready and we encourage you to use it!
To download Flatpak apps in Discover, you need to have the Flatpak backend installed. In many distros, it’s a separate package that doesn’t come installed by default. In Ubuntu-based distros, you can install it by running sudo apt install plasma-discover-flatpak-backend. in Discover 5.12, you’ll even be able to install different backends from within Discover itself, by searching for “Flatpak” or “Snap”. If you want faster Flatpak adoption, please petition your distros to install the Flatpak backend by default!
Once the Flatpak backend is installed, you need to add at least one Flatpak repo. Distros can provision this with default entries, but most don’t. Bug your distro if you want a better experience here! Until then, you can go to Discover’s Settings page and click the “Add Flathub” button to add Flathub as a source. After that, you can access Flatpak apps by browsing or searching through the app lists as normal. You can also go to the settings page and click on the Flatpak entry, which will show you just the Flatpak apps from that repo:
You can add multiple Flatpak repos; to do so, go to the Settings page, click the Hamburger menu button next to the text “Flatpak”, and click “Add Source…” Then enter the URL of the Flatpak repo you want to add. Discover also handles this properly when you click on a repo URL in your web browser.
Multiple Flatpak repos enable users to effortlessly switch between stable and up-to-date versions of apps, each version provided by a different repo. Right now, we’re generally stuck with one or the other, according to our distro’s packaging policy: Arch and other rolling distros say that you always get the latest version; Debian and Ubuntu and other stable release distros say that you always get a specific version that’s frozen in time. Sometimes that’s not right for you, because maybe the latest version has a bad bug, or an old stable version is missing features you want that were implemented in a later version.
Flatpak liberates us from this. You could add Flathub (https://flathub.org/repo/flathub.flatpakrepo) and also KDE’s nightly testing repo (https://distribute.kde.org/kdeapps.flatpakrepo). Then when you go to install a KDE app that’s present in both, you can choose the source! Maybe you want to live on the bleeding edge, but if you run into an issue, you can easily revert your installation to the stable version. It’s pretty awesome.
If any of this seems cool and useful, please don’t hesitate to join our team or make a donation to KDE. My next post shares some specific things you can do to help push Flatpak adoption, even without being a programmer.
Adventures in Linux and KDE 
Nice post! But I think they way to switch provider is not very intuitive. I proposed this UI instead time ago with “versions” tab: http://www.alexl.netsons.org/244/
LikeLike
I have an idea to display all possibilities for installed apps by table. In row description we displays source for package. In column description we display version of package. On cross we display numbers. If some cells contains the same number, then the package version from this source/version can be installed simulate
But I have read, that’s not important, because distros have policy to allow to only install one version of software.
LikeLike
I’m not sure if I agree with the table view ideas; changing the application source/version is likely to be a very infrequent operation to give such visual prominence. We don’t want to hide it, of course, but we don’t want to push it in the user’s face. Even though it’s an important feature, most users won’t ever change the source/version for most or even any of their apps.
LikeLike
I have question. What about installing software to different destination (for example into user’s home directory)?
LikeLike
That’s not a bad idea!
LikeLike
I have found very interesting your work/input into Discover, especially the way that you showed to handle more than one source for flatpaks.
I was thinking that this approach could be useful in also another way: to handle the ‘channels’ of the apps.
Let me explain this using Snap* for the example.
As you may know, Snap uses ‘channels’ for snaps in order to provide packages in various states of development, that goes from stable to edge (stable>candidate>beta>edge).
The current Discover app (stable, at least) only shows the stable packages; using your approach, by clicking on “source”, the box that appears will also provide diferent channels for the same app giving the option to the user to see and decide which branch will want to install, without using the console. I think this will empower and expand the usefulness of Discover.
* First big BUT: I do not know if flatpak uses some sort of “channel” like Snap. In that case, this will be useful to Snaps 😦
Second big BUT: Im not a developer, so I can’t do this myself 😥
Any way, Im happy to see awesome progress in Discover!
LikeLike
Yep, we plan to use exactly the same approach to handle Snap channels.
LikeLike
I wonder how hard it would be to have two versions installed side by side?
LikeLike
In fact you can! Each version is independent of the others, you you can have an app installed from distro packaging, and from multiple Flatpak repos.
LikeLike
AppImage support?
————————
Since for example KDevelop is distributed as AppImage, I wonder if it would make sense if Discover would support programs packaged as AppImage.
LikeLike
There’s no need, really. AppImage was designed to be 100% self-contained, so they don’t need an app like Discover. If you’re familiar with the Mac worls, AppImages are really akin to Mac .app bundles, where you just download them from the developer websites, put then wherever you want on your filesystem, and then double-click to run.
LikeLike
I thought, maybe Discover could be useful to remind the user that there is a new version available or manage different versions of the same Application.
LikeLike
Yes, Discover already provides system notifications about app updates. Are you suggesting messages or notifications on the app page alerting the user that there’s a newer version available in one of the other sources they have configured? It’s an interesting idea.
LikeLike
I meant that if I installed an AppImage, that Discover could notify if there is a newer AppImage available. But probably there is no standard way of how to publish an AppImage so that new versions can be detected. Your suggestion is interesting. That would add the AppImage into the de-duplication process and show updates from other sources.
The other thing: If a user switches between different versions of the same program, I thought recently used AppImages could be integrated in the GUI and provide default locations for installing AppImages (otherwise every user has to come up with a good strategy for himself). Just an idea.
LikeLike
Technically AppImages aren’t actually “installed”. You just dump the file wherever you want and double-click it (after making it executable). Software Centers like Discover don’t really apply, since they’re geared toward managing software that does need to be installed. The process of “managing” AppImages is really done using your file manager!
AppImages are such a blast from the past for me. I was a Mac user for more than two decades (including 7 years working for Apple as an engineer), and Mac App bundles are practically identical to AppImages from a user perspective, down to the same advantages and challenges. Using the file manager to manage apps was (and is) always confusing to non-expert Mac users, and the update process is completely developer-controlled. At one point there was a popular 3rd party framework called Sparkle that enabled automatic updates, but again, it was all up to the developers to implement and use that. There was no centralization until the Mac App store was released.
LikeLike
Maybe create some mechanism to unpack appimage and create flatpak bundle/snap/whatever from it and allow to copy it to repository, so users could have automatic updates for application bundled inn appimage. Off course, it needs to work of distro maintainers, but that’s rather better than compiling it from source. I must also wrote, that somebody must create simple framework for appimage application. This framework will be as minimal as possible (maybe doesn’t contains any executables/libraries).
LikeLike
Sorry for my previous idea. Better is to create flatpak/flatpak-builder switch to generate also appimage from given app and framework. Off course, both idea is not related to discover.
LikeLike
You could use AppImageUpdate for that:
https://github.com/AppImage/AppImageUpdate
LikeLike
Thank you for the post! Helped a lot. However, the package name is not correct / was changed, at least in Debian Buster:
plasma-discover-backend-flatpak
Cheers and thanks a lot
LikeLike
Thanks, but it actually doesn’t matter anymore: since I wrote this post, Discover gained the ability to install its own additional backends from the Settings page!
LikeLike