I guess I’m becoming a Discover developer, since it’s where I seem to spend most of my time these days. It’s just so darn fun since the lead Developer Aleix Pol is super easy to work with, there’s a lot of low-hanging fruit, and with Kirigami, it’s very simple to make consequential changes even when you’re a novice programmer and not very familiar with the codebase. That said, Aleix is still making about 99% of the code changes, and I’m mostly doing UI tweaks, bug screening, promotion, strategy, and work with apps to get their houses in order.

Anyway, here are the user-facing highlights of what we’ve done in the last week or so. There was a lot of work on Snap and Flatpak in particular.

• Snaps now show their size correctly once installed (KDE bug 389024)
• During installation of Snaps, the Install button changes so you can’t click it multiple times (KDE bug 388916)
• Discover now shows the license for Snaps (KDE bug 388735)
• Discover now shows the size for Snaps that aren’t installed (KDE bug 388734)
  
• Discover no longer shows duplicate information in package changelogs for Debian-based distros (KDE bug 387041)
  
• Discover now shows the version number for Flatpak apps that define information in their AppStream files (KDE Bug 388968)
• Discover’s Home page now communicates that it’s a list of featured apps (KDE Phabricator revision D9868)
• Discover now correctly removes the Tasks entry for an app if you cancel the installation (KDE bug 388915)

Let me share a video that shows a lot of the highlights:

We’ve got Kdenlive available from three sources. Version 17.08.3 is available from a distro, and version 17.12.1 is available straight from the developers via Flatpak. You can also get bleeding-edge development builds if you’d like to follow or participate in the development, or verify that a bug is fixed before the next release. You can install the one that suits you best, and change your selection as your needs and preferences evolve over time. It’s your choice.

You’re looking at the future of software delivery, folks.

Do you want to help make this happen? Instead of my usual spiel about becoming a KDE contributor or donating, consider helping app developers correct and expand their AppStream metadata. The video you just saw isn’t possible without it. Let’s go build the future.

What happens in Discover in when an app is available from multiple sources–say, Flathub as well as your distro’s packages?

As long as both versions of the app provide the same AppStream ID, Discover will show a single entry and let you choose which one you want to install, like this:

But if any of the available versions use a different AppStream ID, they’ll show up separately:

Uuurgh, how awful. Which GIMP is the real GIMP? And why do they all have different names?! Flathub uses org.gimp.GIMP as the AppStream ID, while The GIMP developers provide gimp.desktop for distros to use as the AppStream ID. And the Snap version provides no AppStream ID, sadly.

So we need the GIMP developers to change their AppStream ID to the same one that Flathub uses (which actually follows the AppStream spec). I submitted a patch to fix it that was recently accepted, so this should be resolved with the next GIMP release. That will unify the first two, but the third–which comes from Snap–won’t get rolled up into it until Snap uses AppStream IDs. The Snap folks are on the case, but it’s still a work in progress.

But adopting AppStream only work as long as developers are populating their AppStream files with valid IDs! An AppStream ID is supposed to look like com.myurl.NameOfMyApp, not NameOfMyApp.desktop or com.myurl.NameOfMyApp.desktop. Flathub gets this right, but a lot of app developers themselves get it wrong, and it’s up to us to help them, and make sure the AppStream IDs in their files match those on Flathub.

I’ve started to submit patches for apps that unify their AppStream IDs:

• Blender: Fix AppStream ID and add release information
• Inkscape: Fix AppStream IDand add release information
• GIMP: Fix AppStream ID (done) and add release information
• Endless Sky: Fix AppStream ID and add release information (done)
• Hexchat: Fix AppStream ID (done)
• Telegram add release information and use AppStream Data in Ubuntu packaging
• Transmission: Fix AppStream ID
• Lollypop: Add release information
• VLC: Fix AppStream ID (done)
• Pitivi: Fix AppStream ID and add release information
• FileZilla: Fix AppStream ID (done, but need to redo–see discussion here)
• Shutter: Fix AppStream ID (done, but need to redo for the same reason as FileZilla)
• 0 A.D.: Fix AppStream ID
• Audacity: Fix AppStream ID (done)

What can I do to help?

See all those patches I submitted? You can do the same! If you use any apps that have AppStream IDs in their distro packaging that are incorrect and different from what’s in Flathub, then submit a patch to fix it! Keep in mind the following guidelines:

1. Dashes/hyphens must be replaced with underscores: com.shutter-project.shutter is wrong and should be com.shutter_project.shutter
2. Leading digits in the app name are not allowed: com.wildfiregames.0ad is wrong and should be com.wildfiregames._0ad
3. If the AppStream ID used for Flathub is wrong, don’t replicate that wrongness with your patches; encourage developers to use correct AppStream IDs and file a bug for the app on Flathub, like this one.

For extra credit, you can also submit patches that add information, too. This will make the app’s version string show up in Discover:

And here’s the properly formatted information in HexChat’s AppStream file that provides it: https://github.com/hexchat/hexchat/blob/master/data/misc/io.github.Hexchat.appdata.xml.in#L29

I know this isn’t the most immediately rewarding work, but it’s super important to make Flatpak (and later Snap) work properly in a mixed environment where you also have distro packages available. If you want the world to be Snappier or more Flatpacked, this is probably the easiest way to make it happen if you’re not a programmer or a packager. If you need a hand, you can email flatpak@lists.freedesktop.org or check out the #flatpak IRC channel on freenode.org.

As always, if you find this work useful or valuable, please consider becoming a KDE contributor or donating to KDE! But do consider submitting patches for Apps that have sparse or incorrect AppStream data. You’ll be doing your part to pull Linux software distribution into the future.release

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.

KDE Discover Software Center is a key element of our Usability and Productivity initiative because it encompasses the basic experience of discovering, installing, and removing software. Most regular people don’t want to use the command line to do this, and for them, we have Discover.

In the last few weeks, lead developer Aleix Pol has put an enormous amount of work into Discover, fixing bugs and implementing features:

• Add Flathub button now disappears immediately after adding Flathub (KDE Bug 388294)
• “Update All” button is now always visible on Updates page even after you scroll down (KDE Bug 384351)
• Improved search on Updates page (KDE Bug 384463)
• Fixed a large number of crashes (KDE Bugs 384351, 385040, 378339, and 383413)
• Major overhaul of the Settings page UI (KDE Bug 388153)
• Screenshot pop-up now allows navigation (including via keyboard arrow keys) between multiple images (KDE Bugs 387816, 387879, and 387858)
• Screenshot pop-up margins now always match image size and dimensions (KDE Bug 387819)
• App description text no longer cut off when window is resized to be very narrow (KDE Bug 388104)

I even got a few patches of my own accepted:

• App header data is now vertically aligned (KDE Phabricator revision D9542)
• Package changelogs are now shown without a tiny scrollview (KDE Bug 387036)
• Search field now only shows a clear button when there’s a search term (KDE Phabricator revision D9536)
• List of installed apps now sorted alphabetically, not by user popularity (KDE Phabricator revision D9026)

Here are some screenshots of how Discover looks today:

Browse page:

App page:

Settings page:

Installed apps page:

Updates page:

Eagle-eyed readers will notice a few bugs in these screenshots. Those are tracked by the following:

• Discover’s sidebar is too wide (KDE Bug 385992)
• Discover sometimes doesn’t de-duplicate categories from Flatpak backend (KDE Bug 388313)
• Discover’s package update information displays identical information under “Reason:” and “Change Log:” headers on Debian and Ubuntu-based distros (KDE Bug 387041)
• Dolphin shows the icon for Nautilus rather than its own in Ubuntu-based distros (KDE Bug 388702 for Neon; KDE Phabricator Maniphest Ticket T7717 for Kubuntu)

We’re aware of these issues and are actively working to investigate and resolve them. If you use Discover and find any other issues, please feel free to file a bug.

As always, thank you all for your support. If this work excites you or you find Discover useful, consider becoming a contributor yourself or donating to KDE!