Author: Nate

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.

How you can help drive Flatpak adoption

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:

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

Flatpak support in Discover

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.

This week in Usability and Productivity

I’d like to highlight some fixes and features that landed in the past week for our Usability and Productivity initiative:

  • Dragging a Firefox tab to the desktop now detaches it properly (KDE bug 337711)
  • Right-clicking on Discover’s icon exposes a new action that allows you to go straight to the Updates page (KDE Phabricator revision D9637)
  • You can now hide the “Comment” field in Dolphin’s Information Panel (KDE bug 365620)
  • Dolphin’s Properties window now has a tab that shows the same file metadata that the Information Panel does, for people who would prefer to access the information that way (KDE bug 384194)
  • Okular’s dialog box for when a PDF wants to be opened full screen is now presented more naturally (KDE bug 388511)
  • Okular can now Print .djvu files (KDE bug 388514)
  • Discover now de-duplicates categories from Flatpak (KDE bug 388313)
  • Discover no longer lets you scroll beyond the boundaries with the PageUp/PageDown keys (KDE bug 388745)
  • Discover app lists are now more compact (KDE Phabricator revision D9833)

These improvements were landed by KDE Developers Kai Uwe Broulik, Albert Astals Cid, Aleix Pol, Michael Heidelbach, and myself. And that’s not all; the entire KDE community has been busy landing many more bugfixes and features too–more than I can keep track of!

I want to especially focus on the last Discover change I mentioned above. After my last post about Discover, we got a lot of user feedback that people wanted greater density and to be able to see more apps at once. We’ve executed on a part of that, and this is now what Discover looks like if you make the window narrow:

I bring this up to highlight that we really do listen to users. Your feedback matters and we hear it! If you enjoy the results of our efforts, please consider becoming a contributor yourself or donating to KDE! In particular, we would love more contributors for our Usability and Productivity initiative. If you’re interested, please feel free to work on any of these bugs. Here are some that should be relatively easy. Happy coding!

Polishing Discover Software Center

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:

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!