Month: January 2018

Polishing Plasma 5.12

Igor Ljubuncic of Dedoimedo published his review of the Plasma 5.12 beta recently. As always, he’s very thorough, and points out out issues that keep Plasma from being A+ quality. A major part of our Usability and Productivity initiative is honestly acknowledging user feedback and criticism with humility instead of defensiveness or dismissal. That way, rather than engaging in pointless arguments, we can focus on fixing problems!

With our aggressive focus on user satisfaction, we read these kinds of reviews very carefully and take their comments seriously. I wanted to provide a look at all the issues that Igor raised in his review. I went through every issue and made sure that if it was a legitimate bug, it was tracked with a Bugzilla ticket. Many already were, but some weren’t, so I filed tickets for them. Here’s the full list, along with the bugs’ status and our plans for fixing them, where applicable:

  • Can’t easily reset everything to default settings: (KDE bug 389568)
  • Default bottom panel isn’t optimal for using a global menu: this is true, but since the global menu isn’t shown by default, I think it’s fair that if you’re going to use it, you’ll need to change the UI a bit. This is why Plasma is so customizable!
  • Global menu only works in certain programs (e.g. not in LibreOffice or Steamc): it’s unfortunately not something we can fix; this is up to the distros and app developers. Ubuntu’s former Unity global menu feature worked for all apps because Canonical patched the software they packaged to make it work.
  • System Settings window opens too narrow by default: (KDE bug 389617). A trivial change. Will be fixed soon.
  • Sidebar headers are too light: (KDE bug 384638). Not a bad design decision, but rather a a bug caused by the choice of implementation.
  • Slight RGB hinting font anti-aliasing not used by default, even though that’s the best setting: (KDE bug 389598). We may be able to change the defaults here to improve things for the majority of our users.
  • Default font size should be slightly larger with Noto Sans: a controversial proposal, but might be worth it. I plan on doing some side-by-side testing for this.
  • Get Hot New Stuff never seems to works right and is full of outdated content: unfortunately, this is true. It’s a major pain point for a lot of people that we’re aware of and planning to put some work into.
  • Dragging a URL from Firefox to an Icons-Only Task Manager doesn’t work: (KDE bug 389613). Worth mentioning that this mostly works with a regular task manager if you drag it to the region that holds app launchers, not the window list part.
  • Hard to create/differentiate launchers/shortcut icons for multiple versions of an app: (KDE bug 389035)
  • Panel resize UI should have a text box/spinbox to choose the height: (KDE bug 372364). There’s a patch currently undergoing the review process that makes this better!
  • Spectacle should be able to not include window shadows: (KDE bug 372408)
  • Spectacle’s “Save As…” option should be more discoverable: (KDE bug 389614). Trivial fix; will be done soon.
  • Discover app pages look sparse: not our fault, this is entirely on app developers and Ubuntu 16.04 (or KDE Neon, depending on your perspective).
  • Discover doesn’t show app star ratings: (KDE bug 389601)
  • Discover doesn’t show reviews by default: (KDE bug 380514)
  • Discover’s settings page has a scrollbar that overlaps interactive UI elements: (KDE bug 389602). A clear bug; will likely be fixed soon.
  • Discover’s settings/sources page is confusing and exhibits poor usability: Mostly true for distros that have a lot of repos, but a legitimate criticism. We’re discussing this internally.
  • Discover doesn’t offer a way to install NVIDIA drivers or other similar things: Discover is an app store, not a driver manager or a package manager, but we’ll see if there’s any way we can improve this.
  • Dolphin should add Places panel entries for Documents, Download, Pictures, and Music: (KDE bug 389618). A simple enough change, though I think it may take some doing to avoid introducing duplicate entries for existing users.
  • Support for smartphones (especially iPhones) is spotty: A known issue. We’re working on it, slowly.
  • Copying files to samba shared resets their timestamps: (KDE bug 356651). I am actively working on producing a patch for this!
  • KIO doesn’t mount remote filesystems locally like GVFs does: (KDE bug 330192). A major architectural issue. We may need to organize a development sprint for it.

Also, Igor marked as broken a few things that actually do work, or are already fixed in the next versions of the software:

  • You can indeed add folders to Dolphin’s places panel with the context menu!
  • Support for hiding whole sections in Dolphin’s Places panel has already landed in master and should be released with Dolphin 18.04!
  • Konsole tab issues were actually caused by Qt; they changed the behavior of the tab widget and we needed to adapt to that change.
  • Dragging a URL from Firefox’s URL bar to the desktop does create a shortcut to that URL. However, we can improve the usability: (KDE bug 389600)

How you can help

These kinds of issues are major pain points that get brought up over and over again in Plasma reviews and internet discussions. Fixing them has a disproportionate PR impact and generates a stupendous amount of good will. If you’re a developer, please try to hit one of these bugs sometime in the coming days or weeks! it will make a huge difference. This is how we move toward making Plasma a no-brainer choice in the Linux world.

Want to help but don’t know where to start? Read this: https://community.kde.org/Get_Involved

Let all go and polish Plasma to a mirror sheen!

This week in Discover, part 3

This was a design-heavy week in discover, and we landed some bold design improvements to the Application page:

In addition, we fixed bugs, including a few corner-case issues for workflows where Flatpak apps are available alongside apps from your distro. Flatpak support is constantly improving! There are always lots of backend improvements, but here’s the full list of this week’s user-facing improvements:

  • The search field now works again after you go back from an App page, and other focus-related improvements (KDE bug 388835)
  • Long app titles in titlebar are now displayed without eliding, if possible (KDE Phabricator revision D9995)
  • After installing a Flatpak version of an app, trying to launch the PackageKit version from Discover correctly opens the Flatpak version (KDE bug 389036)
  • When an app is available from two Flatpak repos and a PackageKit repo, switching its source to a Flatpak repo no longer makes the PackageKit version temporarily disappear (KDE bug 389186)
  • When the app defines them, show URLs for the user guide, donation page, and bug tracker (KDE Phabricator revision D10131):
    Good Inkscape.png

How to make an app look good in Discover

Why do some app pages in Discover look good, while others look half-finished at best? Why is it that sometimes in some distros (Like Ubuntu 16.04 and KDE Neon) almost all of the app listings are bad? We’ll dive into that today, and see what the plan is for fixing it.

First thing’s first: Discover does not control an app’s presentation. Instead, we display app metadata (such as screenshots, the description, and links to the app’s website) made available to us by the software’s packagers. It’s all up to them to pass on the metadata. If they don’t give it to us, we can’t display it to you!

Where does this app metadata come from? The app developers themselves, from their AppStream file. If an app doesn’t provide an AppStream file, or its file is very minimal and doesn’t provide much content, then the packagers have to create this information themselves. Some packagers do a better job of this than others, as we’ll see. Ubuntu 16.04 is a particular offender, and while it’s gotten better in later releases, every distro based on Ubuntu 16.04 (like KDE Neon) will unfortunately inherit its deficiencies of metadata-poor packaging. This causes app listings to look bad, and frustrated users blame us or the software developers–almost never the distro, even though they make this their job!

Here’s an example of what good AppStream metadata can do for an app:

Perfect Hexchat.png

It’s got:

  • An attractive, high-resolution icon
  • A screenshot
  • A short and useful description
  • A human-readable version number
  • A license
  • URLs for the homepage and user guide, plus links to pages where you can donate or report a bug.

All apps should look this good! It’s pretty easy to get there if developers put lots of information in their AppStream metadata files, and if distros and other software sources make it available to us. Here’s Hexchat’s AppStream file. This is what a good AppStream file should look like! (there’s only a single problem: the ID is set using a non-recommended form: io.github.Hexchat.desktop. This string shouldn’t have “.desktop” on the end of it).

So what’s the plan? We need to get app developers to improve their AppStream metadata. This is an ongoing effort that I’m heavily involved in, but like everything in the FOSS world, it will go much faster if you help!

How users can help

Let’s say you stumble across an app listing that looks like this:

Bad Filezilla.png

There’s no screenshot, and the text looks like it was formatted using Markdown, which isn’t formally supported in most software center programs like Discover, so it shows up as an ugly wall of text. The license is “unknown”, and there’s not even a URL for the app’s website! What a mess.

Here’s another:

Bad HoDict.png

This app provides a low-resolution icon that isn’t very attractive. Its caption (“Ho22bus’s Dict”) gives no indication what the app is or does. As before, the description appears to use markdown rather than HTML, and provides no license or relevant URLs. The app is a mystifying black box.

Here’s how you can help software developers!

First, find the app’s source code repository. Then, within that, locate the AppStream file. It’ll be named something like[appname].appdata.xml. If it looks fine in the developer’s source repo, and you’re using a distro that ships old software like Ubuntu or Debian, it’s likely that the distro packagers simply haven’t included an up-to-date version of the AppStream file, so file bug on the distro’s packaging itself asking them to.

If the file is subpar… then fix it! On the technical side, check out Hexchat’s AppStream file for a great example of how it should look. Design-wise, here’s a great guide from the ElementaryOS people on how to write a compelling app listing that’s largely applicable to Discover as well.

In some unfortunate cases (e..g. Blender), there may not even be an AppStream file. Well, submit one for them! This stuff is really important!

Make sure to validate the file using an XML Validator, and then once it checks out as being valid XML, run appstreamcli validate on it (you may have to use your distro’s command-line package manager to get appstreamcli). Once it passes both checks, submit it back to the developers, either in a bug report, or even a patch or pull request if you know how to do those things.

How developers can help

Please: provide downstream packagers with AppStream files that you’ve taken the time to craft with love and attention to detail. Distros may do your packaging for you, but they’ll never care about presenting your app nicely as much as you will!

If you don’t supply packagers with high-quality AppStream metadata, you’re making life harder for packagers, and your potential users may well be presented with an ugly, even repellant app listing in software center apps like GNOME Software and KDE Discover. Users may blame you, or they may blame us, but either way, they’ll be looking for someone to blame, because bad or nonexistent AppStream metadata will make your app look bad, guaranteed. Here’s the spec. Follow it, and make your app look beautiful, and users will trip over themselves to install and use your software.

Also, submit your app to Flathub! The Flathub people are easy to work with and are delighted when you include high-quality AppStream metadata. Which leads me to…

Flathub rocks

I want to give a shout-out to the people who run Flathub, the de facto central repository of Flatpaked software. They take their role as packagers seriously, even going so far as to create high-quality metadata for apps that lack it. For example, here’s the version of Blender packaged in KDE Neon, which comes from Ubuntu 16.04:

Blender bad.png

Doesn’t look too great, right? Blender is amazing, but you wouldn’t know it by looking at this. Sadly, the Blender developers don’t provide an AppStream file, and the Ubuntu packagers didn’t do anything about it. So Blender’s app page looks lousy.

But here’s the Flathub version:

Blender good.png

Isn’t that way better!? Lots of screenshots, paragraph breaks, a license and website URL… all that information was added by the Flathub packagers. Now that’s dedication.

Want to help out? Be like the Flathub people and improve the metadata for your favorite apps, but then go even farther: submit your changes back to the developers! Here are some examples of minimal patches I or others have submitted to give you a sense of how easy this can be:

Get out there and make some apps look good!

This week in Usability & Productivity, part 3

Howdy folks! Here’s your weekly update on our long-term Usability & productivity goal.  Among many other fixes, KDE contributors landed the following user-visible improvements:

  • If you rename a file in Dolphin and very quickly move the focus to another file, instead of jumping back to the newly-renamed file, the focus now correctly remains on the other file (KDE bug 388555)
  • You can now undo batch rename operations in Dolphin (KDE Phabricator Revision D9836)
  • Dolphin can now show metadata for the date when a photograph was taken (KDE bug 303645)
  • Snap apps no longer show up in Dolphin’s Places panel as mounted devices (KDE bug 379516)
  • Fixed a case where entries in the Places panel were duplicated (KDE bug 389401)
  • Fixed a case where entries in the Places panel weren’t editable (KDE bug 389147)
  • Images in Plasma notifications (e.g. from using Spectacle to take a screenshot) are much less blurry (KDE bug 385097)
  • when the cursor is over a Task Manager entry for a window or app that exposes media playback controls (like a music player), you can now go to the previous and next tracks using your mouse’s back and forward buttons (KDE Phabricator revision D9797)
  • You can now use the Escape key as a shortcut to quit Gwenview (KDE bug 385242)
  • Okular no longer crashes when exporting markdown files to PDF (KDE bug 389216)
  • System Settings’ Cursors page was re-done to offer better usability, with fixes for issues such as KDE bug 375106)
  • When Kate is set to allow scrolling past the end of a document, and you’re currently scrolled past the end of your document, the view no longer jumps up when you type in a visible part of the screen (KDE bug 306745)
  • The Audio Volume widget now indicates with the correct cursor shapes that streams are draggable (KDE Phabricator revision D10098)
  • Tooltips for panel icons are now all sized and aligned in the same way (KDE bugs 386260 and 389371)
  • The System Settings Look And Feel page now immediately changes all UI elements on the page to reflect theme changes (KDE bug 389351)

This is in addition to the design work we did in Discover over the past few days.

Like what you see? Consider becoming a KDE contributor! There are many ways to offer your skills, even if you’re not a programmer. Donating time isn’t your thing? Money helps, too! All of it helps make this possible.

Discover makes your app look gooooood

A common user complaint about Discover has been that the design could use some improvement. We set out to remedy this in the soon-approaching release of Plasma 5.12, with the aid of KDE’s Visual Design Group. VDG members came up with endless ideas and mockups, and we spent weeks discussing things and iterating on the design. I wanted to share the evolution of a single view in Discover: the application page.

In Plasma 5.11, here’s what we started with:

Not bad! But there were some rough edges we wanted to address. The header was full of technical information that wasn’t always what you wanted to see first. The screenshots needed polishing. And that toolbar on the bottom used a nonstandard UI convention.

First, we turned the bottom bar into a real toolbar like the kind that appears on the top of a window:

That fixed that problem, but it made the app display on top a bit disjointed, and exacerbated the problem with having the app metadata on top. And having the app name and icon only in the toolbar made it easy to mistake the caption for the name!

We resolved that by moving the entire metadata section below the description to reduce its prominence, and returning the app name and icon to the page itself in a simplified form:

This revision got high marks internally, but we wanted to go further and ensure that users of Discover in 5.12 received a really polished experience. So we further tweaked the header, increasing the size of each element to increase its visual prominence, and adding a bit more padding. Then we made the screenshot thumbnails reflect the aspect ratio of their full-sized images and gave them a drop shadow to make them pop:

Next, we decided to improve the whitespace and padding even more. We moved over the app name and caption a bit, increased the margins on the sides of the page, and made the description text left-justified:

That screen looks really good because Krita provides an even number of screenshots that all have the same aspect ratio, and they fit perfectly in the window size that I’ve chosen here. But for apps and window sizes that deviated from this, it didn’t look as good. We also felt that the shadows provided a bit too much depth, and competed with their content. Finally with more than four screenshots, the text was pushed down so far you needed to scroll just to see it. So we decided to reduce the shadow strength and put the screenshots in a horizontal scrollview:

This helped! We decided to implement a fade effect when a thumbnail is cut off, and we made the them bigger and taller because with the design, there will only ever be one row:

Whaddaya think? I’ll tell you what I think: it’s fantastic, and you guys are going to really love this app view. I’d like to thank KDE contributors Andres Betts, Andreas Kainz, and Thomas Pfeiffer for their help with the design work, and Aleix Pol for technical work–and for letting me work on his baby Discover in the first place!

Here are some more screenshots showing how it looks with other apps, and in the smaller Plasma Mobile view:

There’s always room for incremental improvement, and there are a few more tweaks we’ll probably make before Plasma 5.12 is released. But we don’t currently have plans to make any radical changes here. We think you’re all going to love this design in Plasma 5.12!

If you like this kind of work, consider jumping on board and helping to push KDE software to even higher heights! Donating helps, too, and allows KDE to sponsor more work and help students travel to KDE events.

Another important task is to get your favorite software to improve its AppStream metadata! Version numbers, screenshots, better text… the better the data we get from apps, the better we can make the app look in Discover.

KDE Contributors: Your work matters to people

Browsing through the list of past donations, I came across this from last December:

This feature was implemented by one of our newer contributors, Andreas Krutzler, who’s already making a name for himself with some high-quality work on Dolphin. Great Job, Andreas!

Sometimes our labors can seem a bit abstract, but as the above screenshot shows, it makes a difference. Our software gets used every day by millions of real people with real needs, frustrations, challenges, and triumphs.

And for potential and current financial contributors: your donations make a huge difference, and we notice these kinds of messages. This support and encouragement is the wind in our sails.

Keep on making the world more awesome, everyone.

This week in Usability and Productivity, part 2

This is your weekly status update for the KDE community’s progress in the Usability and Productivity initiative. KDE contributors have been busy, and here’s a sampling of features, improvements, and bugfixes relevant to the initiative that KDE developers landed over the past week-and-a-half (subsequent reports will be weekly, but I wrote the first one in the middle of a week):

  • KIO file copy speed (e.g. in Dolphin) is now 4.5x faster (KDE bug 384561)
  • Fixed a layout glitch in Open & Save file picker dialogs (KDE bug 352776)
  • KMail gained the ability to badge its Task Manager app icon with the count of unread emails (KDE Phabricator revision D9841)
  • Notification badges on Task Manager app icons now show up in Task Manager tooltips, too (KDE Phabricator revision D9825) and look better for huge numbers (KDE Phabricator revision D9827):
  • The Audio Volume widget now looks good with Dark themes (KDE bug 388766)
  • KSysGuard’s CPU column now has a pretty little CPU use graph in the background for each process (KDE Phabricator revision D9689):
  • Every KDE app’s “Settings > Configure [app]” menu item now has a universally consistent keyboard shortcut: Ctrl+Shift+Comma (KDE Phabricator revision D8296)
  • The PDF thumbnailer is able to generate thumbnails in Dolphin for more types of PDFs (KDE bug 388288)
  • Dates are no longer formatted like numbers (i.e. as “2,018”) in some places in Dolphin (KDE Phabricator revision D9887)
  • The menu you get when right-clicking on KAddressBook’s icon now includes a “New Contact…” item (KDE Phabricator revision D9926)
  • Dolphin’s main view now properly regains focus after you close the inline terminal pane (KDE bug 298467)
  • Window titlebar buttons now show tooltips (KDE bug 383040)
  • Plasma’s notifications no longer leak memory when created (KDE bug 389132)
  • Baloo indexer now actually excludes directories that are marked as excluded from indexing (KDE bug 362226)
  • A whole class of app crashes caused by typing or deleting characters in search fields using Qt QML components (such as in Discover and System Settings) was traced to a Qt bug–and KDE developer Aleix Pol has submitted a patch!

There’s also been a ton of work in Discover, particularly in Snap and Flatpak support. You can read about it here.

If any of this seems cool or useful, consider helping us out by becoming a KDE contributor yourself. If donating time isn’t your cup of tea, we always appreciate donations of money, too. We can’t do this without your support!

What about AppImage?

I see a lot of people asking about state of AppImage support in Discover.

It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager

This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.

It’s the same model. For 20 years, there was no centralized Mac App Store because this distribution model doesn’t require it. Apple did eventually create one, but it’s a shadow of the iOS version, and a lot of popular Mac developers never got on board, continuing to distribute software themselves and update it in the way they choose (often with Sparkle).

When a format’s primary advantage is decentralization and independence, you don’t need a centralized piece of software like Discover do manage it. Of course, it would be nice to be able to have a centralized location to browse AppImage vendors, but a simple website could accomplish that.

AppImage isn’t currently a part of our design because Software Stores aren’t a part of AppImage’s design. We don’t oppose it–nothing of the sort! But the format isn’t relevant to what Discover does. If you want to use AppImage, go ahead! It’s a great format, and you don’t need our help to do it.

Videos on Samba shares

A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.

Background

For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.

KDE does have a KIO-aware video player that could do the job: DragonPlayer. Unfortunately, it’s not actively developed, and a bug prevents this from working.

That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!

The problem

…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.

The solution

Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.

Unfortunately (but understandably), the MPV developers denied the request. But the VLC developers didn’t, and actually implemented KWallet support in VLC 3.0! But when I tested it using nightly builds of VLC 3.0, I found that it didn’t work, and had even regressed from version 2.

Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.

Behold, the power of QA!

Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:

After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.

Lessons learned

QA is important. If people don’t test features, apps could ship broken.

Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.

The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.

This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.

Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.

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.