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 <release> information, too. This will make the app’s version string show up in Discover:

And here’s the properly formatted <release> 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!

Richer Shadows

KDE’s Visual Design Group recently put some thought into shadows in Breeze. Right now, the default shadows are rather small, and can be almost entirely invisible on the left edge:

We decided to make them larger and deeper by default, and center them horizontally so that there’s a shadow on the left edges of windows and menus as well. I was honored to produce the patch, and I’m happy to report that it’s been accepted and merged! Starting in Plasma 5.12, here’s how shadows will look:

These are just default settings of course; if you don’t like big shadows, you can tweak to your heart’s content (System Settings > Application Style > Window Decorations > [click on the little menu button in the corner of the Breeze entry] > Shadows). But this new default setting provides a much greater sense of depth that I think most users will find quite welcome.