Why I only have one computer

If you’re here for just the KDE-specific stuff, feel free to skip this post.

I used to have a desktop and a laptop. But in the end I found that having only a single machine greatly simplified everything and increased my productivity. This is it:

Just a regular old Lenovo ThinkPad X1 Yoga laptop

The biggest problem was always keeping files in sync.

Assuming you’re more than just a consumer of online content, you probably have local files for things that are important to you: school work; in-progress projects; creative pursuits; family photos; a personal music collection; source code repos; saved memes–you name it. With more than one computer, you need to figure out a way to keep these files in sync, and good solutions are elusive.

Cloud services are expensive and may compromise your privacy. Free non-cloud local sync services only work when both machines are on the same network. Any FOSS versions of these are unfortunately buggy and a chore to set up and maintain. Even if your chosen sync solution works perfectly (which it never does), you have to deal with the headaches of:

  • Inevitable sync conflicts
  • The set of files on one computer exceeding the storage capacity of another one
  • A necessary delay before you can work on files which the sync service is still updating after you turn on a computer that was turned off while changes were made on another computer
  • Resisting the temptation to pause syncing when something goes wrong, because you will forget to turn it back on, causing each computer’s files to drift out of sync and making reconciliation that much harder later

If you opt to forgo sync services and instead store common or shared files on a server (say, music or movies), this worsens the problem because now you have an additional location of files to manage, and you acquire the challenge of how to either safely access the files when not on the server’s local network, or automatically keep cached local copies in sync.

Giving up and keeping differing sets of files on each computers defeats one of the advantages of having multiple computers, and makes file management a real nightmare because you will somehow never have the file you want on the computer you happen to be using at any given time.

There’s just no good way out here, at least not that I’ve found.

In the end I settled on using a single computer–a powerful, top-of-the-line laptop. This can do everything a desktop can do–albeit more slowly–but it has the portability I need for travel and working from multiple locations. Interestingly, one really nice laptop that doesn’t need an external screen, mouse, or speakers turns out to be generally cheaper than two decent computers with all their associated peripherals. The only problem is finding one, because the range of high-end PC laptops kind of stinks, unfortunately. More on that tomorrow.

Bug triaging is the foundation of quality and we need more of it

Bug triaging is a largely invisible and often thankless task. But it’s the foundation of quality in our software offerings. Every day, our users file between 30 and 50 bug reports on https://bugs.kde.org, and often up to 100 right after a big release! Many will be duplicates of pre-existing issues and need to be marked as such. Quite a few will be caused by issues outside of KDE’s control and this also needs to be marked as such. Many will be crash reports with missing or useless backtraces, and their reporters need to be asked to add the missing information to make the bug report actionable. And the rest need to be prioritized, moved to the right component, tagged appropriately, and eventually fixed.

All of this sounds pretty boring. And, to be honest, sometimes it is (I’m really selling this, right?). But it’s critically important to everything we do. Because when it’s not done properly:

  1. Users don’t feel listened to, and start trashing us and our software on social media.
  2. Critical regressions in new releases get missed and are still visible when reviewers check out the new version, so they also trash it in high-profile tech articles and videos.
  3. Un-actionable bug reports pile up and obscure real issues, so developers are less likely to notice them and fix them.
  4. Bugs that occur over and over again don’t accumulate dozens of duplicates, don’t look important enough to prioritize, and therefore don’t get fixed.
  5. Easy-to-fix bugs don’t get fixed by anyone and it’s pretty embarrassing.

Do you see a pattern? Most of these results end up with KDE software being buggier and KDE’s reputation being damaged. It’s not an accident that KDE’s software is less buggy than ever before that that we enjoy a good reputation today. These positive developments are driven by everyone involved, but they rest upon an invisible foundation of good bug triage. And as KDE software becomes more popular, users file more bug reports. So the need for bug triage constantly grows. Currently it is done by just a few people, and we need help. Your help! And it will truly be helpful! If you are a meticulous, detail-oriented person with some technical inclination but no programming ability, triaging bug reports may just be the best way to help KDE. If this sounds like something you’d like to get involved with, go over to https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging and give it a read! I would be happy to offer personal bug triaging mentorship, too. Just click the “Contact me” link here or at the top of the page and I’ll help you get started.

PSA: try turning on WebRenderer in Firefox

This is a new rendering backend for Firefox that’s not yet on by default. Presumably there are some edge cases where it makes things worse or causes some instability, but so far I have not experienced anything bad. On the contrary, without it, I and some other people get terrible flickering in Firefox on Wayland. With it enabled, not only is the flickering gone, but scrolling performance becomes buttery smooth and CPU usage decreases noticeably on both Wayland and X11, resulting in increased battery life! Win-win-win.

To turn it on, visit the about:config page in Firefox, search for “gfx.webrender.all”, and set it to true. That’s all there is to it!

I’m on Patreon now

Howdy everyone! So many folks have asked me to set up a Patreon page that I’ve gone and done it: https://www.patreon.com/ngraham

By supporting me on Patreon, you’re helping me provide the focus, direction, support, and technical contributions that work to turn the KDE software suite into a lean, mean, bug-free productivity machine, and get it distributed well so that our users have great options for getting our software.

Of course, I’m only one man; what really matters is not me, but rather you! KDE’s greatest strength is its passionate community of developers and users, who work tirelessly to develop, improve, polish, promote, and use KDE software. I truly couldn’t do this without all of you, and in fact, I wouldn’t even want to! All of you are the reason why I work so hard on KDE software. Thank you, so very much.

Become a patron

The future of distros

Today KDE released Plasma 5.12 with Long Term Support–the culmination of more than a year of work. It’s really awesome, and we think you’ll love it!

But how do you get it!?

It all depends on your distro! Let’s look at Linux distros today.

What makes a distro a distro?

Today it’s mostly the choice of release model. “Stable release” distros like Ubuntu and Linux Mint lock everything to a specific version, only offering feature upgrades only when a new major version of the distro is released. “Rolling release” distros like Arch and openSUSE Tumbleweed give you everything as close to the developers’ schedules as possible.

Each model has drawbacks:

  • Stable release distros will often saddle users with ancient, years-old software. For example, users of Debian Stable might not get to experience KDE Plasma 5.12 for another 2 or 3 years–or even longer.
  • Rolling release distros expose users to the latest version of everything, turning them into QA. Underlying system libraries often change and break apps that use them. The breakage is usually fixed quickly, but users are exposed to it in the first place.

Certain distros additionally try to go beyond mere packaging and releasing, and actually try to ensure some QA and polish in the final product. Distros like Ubuntu, Linux Mint, Manjaro, and Elementary that follow this model quickly rocket up to the top of the popularity pyramid. Users are desperate for distros with better QA and polish!

But it’s exhausting; if you package all the software, you’re responsible for it too. It’s a huge job, even for distros that base themselves on others, as they find themselves having to patch on top of patches, and manage two release cycles (their own, and the parent distro’s). Turnover and burnout are common.

Flatpak and Snap to the rescue

Flatpack or Snap provide the solution: 3rd party packaging. Instead of the distros doing the packaging, it comes either straight from the developers, or from a 3rd-party intermediary like Flathub.

For distros, the benefits are enormous: liberated from the grunt work chores of packaging and patching software, distros will be free to step wholeheartedly into their natural roles as arbiters of the final user experience, concentrating on impactful tasks like integrating diverse components, managing hardware support, performing QA, polishing the final product, and delivering it to users in an easy-to access manner. Fixes and patches can be submitted upstream, instead of duplicated locally. This is KDE’s relationship to Qt, in fact. It works great.

Snap and Flatpak also improve things for users and developers:

  • Users get to choose whether they want each app to be stable, up-to-date, or cutting-edge according to their preferences, and they get a clear chain of responsibility when there’s a bug.
  • Developers get to package their apps only once to make them available to everyone, and get to determine for themselves their software’s presentation, branding, and release schedule–rather than hoping that packagers for 500 different Linux distros do it for them, and then having to deal with bug reports about versions of their software that are years old.

Ultimately, Flatpak or Snap liberate us from the tyranny of low-quality distros that make Linux software look bad because they don’t do QA, integration, or UX testing to make sure that the final product is of high quality. Many will rightly vanish because they’re not providing much value for users or generating enough developer interest to continue existing. Once this happens, developers and users will gather around the smaller number of remaining distros, increasing each of their levels of manpower and user bases.

So no, distros don’t go away. In fact, the distros that are worth keeping will be able to focus on tasks that offer more value to users than mere software packaging. Far from erasing diversity, this will empower real and meaningful diversity–where we have a handful of really good and strongly differentiated distros whose products embody different philosophies, instead of an overwhelming number of mediocre distros with often only minimal differences, none of which really work well once you dig deeply. We’ll all win, and all of these vastly superior distros will be far stronger contenders when compared to Windows, macOS, and ChromeOS.

How you can help

There are many ways for you to help enter this brave new world of actual QA and polished products.

Users: If your favorite app offers a Flatpak or Snap version, use it! Quite a lot do. If you find problems, file bugs! If you find an app listing in KDE Discover or GNOME Software that doesn’t look good, submit better information! If you find cases where duplicate apps appear when browsing, submit patches to fix it!

Software developers: Provide high-quality AppStream metadata and please submit your apps to Flathub! This goes for KDE developers, too. Krita and Kdenlive are already up, but I want to see Dolphin, Konsole, Kate, and all the rest!

Distro developers: don’t fight Flatpak or Snap; embrace them (and Flathub) and liberate yourself from packaging chores. Focus less on packaging software for your users, and more on performing the QA necessary to make sure that that software actually works well.

As always, consider becoming a KDE contributor if you like what you see! We can’t do this without you.

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.

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.


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.

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.

KDE Goal: Usability and Productivity

It’s been an honor to have had the community select my KDE goal: focus on usability and productivity. This is a topic that’s quite dear to my heart, as I’ve always seen a computer for a vehicle for giving substance to your thoughts. Low-quality computer operating systems and software get in your way and knock you out of a state of flow, while high quality versions let you create at the speed of thought. KDE Plasma is already pretty good in this department, but I think we can make it even better–we can turn it into the obvious choice for people who need to get things done.

To make this happen, I’m proposing to focus on the following broad approaches:

  • Make it easier to find, install, launch, update, and remove new software
  • Increase the speed and efficiency with which files and data can be transferred from one program or context to another
  • Write new features that make common operations easier, faster, more efficient, or less frustrating
  • Make common features look and behave identically to make use of users’ pre-existing muscle memory and knowledge of how things work
  • Fix bugs that make important features not work properly or at all
  • Improve the state of laptop touchpad input with libinput, which is rapidly becoming the new standard
  • Fix commonly-complained-about visual design and UX issues

In the past month, KDE contributors (myself included) have implemented the following important improvements–many of them commonly wished for:

  • Improved the default size of the Clock widget’s text (KDE Bug 375969)
  • Worked with the VLC devs to make VLC 3.0 work out of the box for streaming videos over Samba shares on KDE desktops (VLC Bugs 18993 and 18991)
  • Made sections in Dolphin’s Places panel hide-able (KDE Bug 300247)
  • Added a dedicated section for removable devices to open and save dialogs (Phabricator revision D8348)
  • Made Gwenview open Targa Image (.tga) files KDE Bug 332485)
  • Gave Gwenview’s move/copy/link dialog a title that reflects the selected files (Phabricator revision D8409)
  • Got Discover’s screenshot pop-ups navigation buttons that respond to keyboard arrow keys (KDE Bugs 387816, 387858, and 387879)
  • Implemented a Wayland-compatible Redshift-esque Night Color feature (KDE Bug 371494)
  • Restored advanced print options to the Qt print dialog (Qt Bug 54464)

And we’re just getting started! You can find a longer list of the improvements we’re targeting in the coming months and years on the proposal page, and the full list here on our Bugzilla.

How you can help

If you have programming skills, please feel free to work on any of the above bugs. Patches are submitted using Phabricator; additional developer documentation can be found here.

If you’re more visually inclined, please feel free to start giving feedback and input in the KDE Visual Design Group chatroom.

If you’re detail-oriented and like categorizing things, we’re always in dire need of bug screeners and triagers. Every day, KDE receives on average 15-25 new Bugzilla tickets. Many of these are duplicates of existing bug reports. Many have already been fixed. Many are caused by configuration issues on the reporter’s computer. And many are real bug or legitimate feature requests. But without bug screeners to categorize them appropriately, they just all pile up into an intimidating mountain. It’s an important job; the bug lists above could not have been compiled if not for KDE’s bug triagers. Read more about it here!

And finally, financial contributions are very much appreciated, too. KDE’s annual fundraiser is going on right now, so hop on over and donate! Every little bit helps.