This week in Discover

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.

17 thoughts on “This week in Discover

  1. Great work! Discover is looking better and better with every release.

    Just an observation based on what I see in the video – to an end user it’s not clear that there are multiple sources available. The links below “Source” are to the licence and homepage which users likely to ignore too. Perhaps you could some text like “3 versions available for different sources” or something to that effect. That would also make it clear you are talking about the package source and not the source code.


    1. I agree. We’re discussing internally how best to refine or change the “multiple sources are available” UI.


    1. That was actually what we had before, but it was less readable because the text coming after the labels wasn’t aligned.


  2. Can you install kdenlive from ditro repos AND additionally install Flatpack version AND if new Flatpack will be available then have an option to add it and not replace?


    1. Yes, you can have distro and Flatpak versions installed simultaneously. When the Flatpak version is updated, it will replace the old version.


    2. Could you also add an option so that when new update for Flatpak is available the user could choose to install it separately instead of updating the existing one? That was one of the selling point for Flatpak, to have multiple versions in the system. And also an option for a user to manually choose one of those two flatpaks to be updatable in the future while the other one would be freezed.


    1. For example you’re using a program that have two branches, stable(version 2) and something that will become new stable(version 3). But author wants to build only 1 stable Flatpak so the next time Flatpak is updated users will be upgraded to new major version. Version 3 might and likely will still have some issues that you won’t have time to deal with because your work/task requires you to do the job yesterday. But you also want to test new version when you have some time and report bugs if any. In this case having few versions is way better than downgrading -> upgrading -> downgrading cycle.


    2. For this use case, it seems like a more elegant approach would be to always retain the prior version of the application after an update, so you could instantly roll back if you had a problem with the new version.


    3. No its not really. One advantage that Flatpak gives us is an option to have different versions of the same program installed in the system. You can rollback with any package right now, its not as convinient as simply launching one of the versions you need right away. You can ask people that work with Blender or Maya, most of them have multiple versions installed simply because projects require it(if something needs to be fixed or you need an addon that wok well only in older version, for example). For Blender its easy on any platform, they provide official portable version, for Maya its easy on Windows but in Linux you’d have to manually adjust many things. Basically before Snap/Flatpak there was no widely excepted working solution to have many versions of the same program. It may not be the most used feature but when you need it its better be there. And since you’re making life of us, average users, simpler please give us an option to not go into console to use this kind of feature.


Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s