KDE roadmap for 2021

Just like last year, here are the things I expect will get done in 2021:

Leftovers from last year

We’ll finally finish up polkit-in-kio, which got closer in 2020 but didn’t quite make it. 2021 will be the year! We will probably also get power/session actions in the lock screen as this feature is necessary for Plasma Mobile, and making it work in the Plasma Desktop session as well will be fairly simple. Per-screen scaling on X11 seems unlikely given our renewed focus on Wayland, and on that subject…

Production-ready Plasma Wayland session

I’ll be honest: before 2020 the Plasma Wayland session felt like a mess to me. Nothing worked properly. But all of this changed in 2020: suddenly things started working properly. I expect the trend of serious, concentrated Wayland work to continue in 2021, and finally make Plasma Wayland session usable for an increasing number of people’s production workflows.

Fingerprint support throughout the stack

This is already in progress! It’s a lot of work because support needs to be added in SDDM, the lock screen, KAuth, Polkit… There are a lot of moving pieces to put together. I think 2021 will be the year that it finally happens!

Finish up Breeze Evolution

This work is in progress and about half of it has already been merged, to be released in Plasma 5.21. I expect the rest will land in Plasma 5.22 and possible 5.23 later in the year. At that point, the project will be complete and our apps will look super modern and awesome!

Kickoff replacement

A super-fantastic replacement for the venerable Kickoff application launcher has been in heavy development throughout 2020, according to the spec that VDG wrote in 2019. It’s almost done, and I expect it to be merged soon and be released in Plasma 5.21.

Reflowing text in Konsole

This is already in progress and very close to being done! 2021 will be the year that Konsole’s window finally re-flows the text when you resize it.


I feel like we’re getting really really close to the goal of having a mainstream-hardware-ready software stack. In some ways we’re already there, especially when you compare our stuff to some of the weaker offerings in the market. We need to keep plugging away, and start thinking about the next steps: more hardware partnerships, closer coordination with distros, and more engineering effort for our own Neon distro. 2021 is going to be a great year for KDE and KDE users! So what are you waiting for? Get involved! 🙂

Highlights from 2020

2020 was not an amazing year for most of us, but it sure was for KDE and people who use KDE software! Despite the inability to travel and meet for sprints, conferences, and Akademy in person, we kept busy.

I’d like to highlight some of my favorite improvements throughout KDE! Keep in mind this is not even a small fraction of everything that went on. To keep this post from ballooning a hundred pages long, I’ve had to leave out many smaller features, all of the performance and bugfixing work, and tons of KDE apps that I don’t closely follow, including big important ones like Krita, Kdenlive, Digikam, and GCompris. You can find more news at https://planet.kde.org/.

Also, those of you who like podcasts or are audio learners can listen to a condensed version of this post in the Linux Unplugged podcast #385, where I spoke a bit about some of these things:

Roadmap items

From last year’s proposed roadmap, we got FUSE mounts, improved Samba share discovery, automatic screen rotation, and Breeze Evolution visual overhaul work starting to land!

We did not get PolKit privilege escalation, new photo wallpapers, per-screen scale factors on X11, or inertial scrolling in Plasma and QML apps, or power/session actions on the lock screen. Some of these will be punted to next year. More on that tomorrow!

Hardware Partnerships

We created a new page on the kde.org website showcasing the ways that you can get Plasma pre-installed on hardware: https://kde.org/hardware/. It showcases two very exciting new devices:

Wayland

This year massive progress was made on the Plasma Wayland session, including screencasting support, shared clipboard support in Klipper, support for middle-click-paste, support for multi-GPU output, support for thew KRunner windows runner, Task Manager Window thumbnails, screen rotation, High DPI screenshot and timer support in Spectacle, the virtual keyboard now works for GTK apps, configurable mouse and touchpad scroll speed, and global menu support. Phew! You can read more about it on Aleix’s blog: https://www.proli.net/2020/12/30/my-2020-with-kwin-wayland/

Websites

The following websites were created or overhauled to modern standards and content:

https://akademy.kde.org, https://api.kde.org, https://apps.kde.org, https://calligra.org, https://dot.kde.org, https://download.kde.org, https://elisa.kde.org, https://ev.kde.org, https://juk.kde.org, https://kdeconnect.kde.org, https://kde.org, https://kde.org/for/kids, https://kde.slimbook.org, https://kid3.kde.org, https://kmymoney.org, https://konversation.kde.org, https://my.kde.org, https://planet.kde.org, https://relate.kde.org, https://season.kde.org, https://subtitlecomposer.kde.org

Check ’em out; they look great!

Akademy

We had our first virtual Akademy, and it went very well thanks to KDE’s talented sysadmins! You can watch the video recordings of all the talks, workshops, and other content at https://www.youtube.com/c/KdeOrg/videos.

Infrastructure

We began the process of migrating to GitLab at https://invent.kde.org! Thus far we are using GitLab for code review, and are working on migrating the continuous integration system next. After that will be Phabricator Tasks, and then hopefully bug reporting (a man can dream).

We also began the process of migrating to a totally new single sign-on system: https://my.kde.org. Read all about it here: https://carlschwan.eu/2020/10/03/announcing-mykde/

Plasma

We kicked off the year with the Plasma 5.18 Long Term Support version, which was received very well, and is shipped in Kubuntu 20.04 and openSUSE Leap 15.2.

It was a big year for Plasma and Breeze app styling. The overhauled visuals we’ve been working on for years started landing, including a defined header area in apps and plasma applets, an updated Breeze Light color scheme that’s now used by default, a new more compact OSD style, and a new optional hybrid dark/light theme. To top it all off, Plasma now uses an Icons-Only Task Manager by default.

We also did a massive overhaul of the System tray from top to bottom: all of the applets were polished both visually and functionally, most bugs were fixed, various new features were added, and the whole thing was made more cohesive overall.

The Digital Clock also received a lot of attention, gaining a fancy new popup that shows timezones, an overhauled page for adding, removing, and switching timezones, and the ability to set the first day of the week. It also shows the date in its panel version by default.

The rest of Plasma gained many new features including a fancy new “Get New [Thing]” dialog, a new System Tray applet for controlling Night Color, new System Monitor applets, a new system monitoring app, a new inline character palette for entering alternative characters, the ability to set a maximum charge limit for laptop hardware that supports it (like Lenovo ThinkPads), and the ability to reply to notifications inline, in apps that support it (like Telegram).

On the backend side, Plasma now has full touch support for Folder View/desktop items, and optional Systemd integration, which improves startup times and gains the ability to group processes by app.

Plasma Mobile also had a banner year, attracting a number of new developers and undergoing heavy development work, culminating in the PinePhone product running Plasma Mobile!

System Settings & Info Center

System Settings and Info Center (which now uses the System Settings app as its backend, sharing code) gained various new features, including automatically syncing relevant system-level Qt/KDE app settings to GTK apps, a “Highlight Changed Settings” feature, the ability to download new KRunner Runners from store.kde.org, a new S.M.A.R.T. Monitoring page and notification system, a new Network Interfaces page, a completely overhauled Samba page. We also ported many System Settings pages to QML. This makes those pages usable in Plasma Mobile and provides an opportunity to modernize the UX. Ported pages include Accessibility, Autostart, Background Services, Bluetooth, Desktop Session, Screen Locking, Shortcuts, Users, and Window Rules.

Those orange dots show which pages have any settings that have been changed from their default settings

KWin

In addition to the aforementioned Wayland work–almost all of which heavily involved KWin–our venerable window manager gained support for clipped subsurfaces and the ability to tile windows to a corner by combining the side tiling shortcuts. We also changed the window dragging shortcut to Meta+Drag to avoid conflicts with popular apps, and made minimized windows no longer automatically move to the end of the Task Switcher. All of this in additions to tons and tons of bugfixes and performance work.

Applications & Frameworks

All KDE apps now support AV1 images, support copy-on-write support when using the BTRFS file system, and remember the positions of their windows, including on a per-screen-arrangement basis.

Dolphin and file management

It was a big year for interacting with remote files. First, we released kio-fuse, which makes the experience of dealing with remote files a hundred times better. We integrated WS-DISCOVERY support which makes Dolphin able to locate modern Samba shares, and overhauled the Samba share creator to work much better. Dolphin also gained full touch support, a plugin to mount ISO images, the ability to display real on-disk sizes for folders in Details view. Dolphin also now displays its URL navigator/breadcrumbs bar in the toolbar by default, and remembers its prior window state by default.

Elisa

Elisa gained many features including the ability to edit song metadata, change the sort criteria, remain playing in the background with only a System Tray item visible, repeat one track, display the contents of a category in the sidebar, and override the systemwide color scheme. Finally, the “Previous track” action goes back to the beginning of the current track unless playback is within the first 5 seconds.

Kate

Kate turned 20! To celebrate, its tab bar now has a standard appearance and new tabs are opened on the right. And the app–as well as other text editor views based on the KTextEditor framework–now fully respect your systemwide color scheme! You can read more about it on the Kate blog here: https://kate-editor.org/post/2020/2020-12-31-kate-in-2020/

Konsole

Konsole gained a variety of useful new features such as inline previews for images and HTML color codes that you hover the cursor over, the ability to assign custom colors to tabs, and a new on-by-default toolbar. Also, paths in grep output are now clickable to jump directly to that line of code in the file!

Okular

Okular gained the ability to digitally sign documents and now offers (optional) smooth scrolling, which was a bit rocky at first, but we fixed it. 🙂 The Annotations feature was totally overhauled with a new toolbar that makes it easier to change the parameters of an annotation, and and there were various UI improvements to the sidebar and the default toolbar. Okular also adopted date-based versioning, matching most other KDE apps using the release service. 🙂

Spectacle

In addition to the aforementioned Wayland improvements, Spectacle gained the ability to annotate newly-taken screenshots!

How very meta

And remember, this is just a subset of a subset! KDE has over a hundred other apps which you can find out about at https://kde.org/applications. And I didn’t even mention some of the amazing stuff that’s still under development but not yet released, like a firewall control UI for Plasma and totally re-worked compositing in KWin which will result in support >60hz screen refresh rates and mixed refresh rates in multi-screen setups. Stay tuned for more information about that stuff and more. 🙂

How KDE can transcend the cycle of Geeks, Mops, and Sociopaths

A few years ago I read a fascinating article about the cycle of how subcultures grow, mature, and die. The whole thing is worth a read (as well as the whole site), but here’s the abridged version:

  1. Creators invent something new and cool, attracting fanatics who validate them and help spread it around. These people are the “Geeks.” I would guess that most current users of KDE software are in or near this group.
  2. The coolness attracts “Mops”–normal people who want to enjoy the cool thing with minimal effort or investment. They dilute the coolness by demanding that it be simplified, sanitized, and mainstreamed for them. In KDE terms, these people would be our non-technical friends and relatives.
  3. At this point, the Geeks may start to quit because the coolness has been destroyed by the Mops. However sometimes the Geeks realize that Mops are key to expanding the cool thing even further.
  4. At this point Sociopaths will appear–people who participate in a system for the money or power games. They figure out how to monetize the Mops, allowing some Geeks to go pro and create the cool thing full time.
  5. Sociopaths increasingly exploit both the Geeks and the Mops, because they’re in it for the money and social power.
  6. The Geeks increasingly burn out because they’re spending their time unpleasantly interacting with exploitative Sociopaths and compromising their original vision to placate demanding Mops who provide their income.

I’m old enough that I’ve started to notice this cycle play out in various hobbies, subcultures, and even commercial companies I’ve been involved with: they start out small and cool, but along the way, mainstreaming and commercialization seem to corrupt everything.

I’ve also noticed that many FOSS projects seem to avoid this cycle and the dark fate at the end. Not all do, but some seem to. Why? How?

How FOSS helps

In the FOSS world, Mops are not easily monetized. The product is given away for free, after all! Only mildly Geeky Mops will be attracted, and the more entitled mainstream Mops can be told to pound sand when they start to demand more. They didn’t pay anything, so they’re not entitled to anything.

As a result, many FOSS projects are able to preserve their stable niche status because they explicitly reject a strong Mop appeal, limiting the attractiveness for Sociopaths. To tie this fairly theoretical discussion back to the software world a bit, Arch Linux is a good example: not having an installer acts as a gate to keep out low-investment Mops, ensuring that the project remains safely in the hands of the Geeks.

However this kind of gatekeeping–intentional or not–has a drawback: if the gate is too strong, the project may shrink over time as the original Geeks get bored or driven away by internal politics. Because the pool of Geeks is fairly limited, Geek-only growth largely involves poaching from other Geek projects; it’s a zero sum game.


What to do? Is it really a matter of keeping out the Mops and staying small, or letting them in and burning out after growing huge? And how am I able to reconcile knowledge of this cycle with my stated goal to get KDE Plasma onto every computing device on planet Earth? Earthlings are mostly Mops, after all.

How KDE can do it

Well first of all, I acknowledge that my goal is more aspirational than realistic. 🙂 Better to shoot for the moon and fall short, I think. I’d be pretty happy if we get Plasma to 15% global market share. That’s enough to be a major player with a direct and ongoing positive impact on human civilization.

Anyway, here’s how I think KDE can avoid the cycle, and grow powerful without being corrupted:

Attract all the Geeks

You may notice how many sysadmins, software devs, and general nerds have Apple computers outside of the FOSS world. In the early 2000s, Apple attracted a huge number of Geeks by pairing support for power-user workflows with an attractive user interface and high reliability. This was the “It Just Works” factor, for people who were doing work. It allowed Apple’s ecosystem to maintain a favorable Geek-to-Mop ratio, at least until the iPhone took off. KDE can realistically follow this path as well. I myself am a former Apple nerd. We can convert them. And the more Geeks KDE has, the more engineering talent it will accumulate, and the more Mops it can safely support.

Minimize the project’s reliance on Mop money

This avoids creating a financial incentive to dilute the product, and it reduces the project’s appeal to Sociopaths (at least, the ones who are attracted to money). KDE already has this pretty well covered, because we don’t sell products directly to consumers for money–with the exception of Krita on the Windows store (to my knowledge), and even then there are simple ways to get Krita for free if you want. The existence of a free version is a pressure valve.

Preserve the KDE community’s gravitational center for development

Today KDE benefits from outside companies paying people to work on KDE who are benevolent: Blue Systems (my employer), Enioka Haute Couture, KDAB, SUSE, the city of Munich, and various others. But it won’t always be this way as KDE rises in importance.

Large companies with little exposure to the FOSS world, but who use or sell products with KDE software, will want to hire their own engineers to contribute to KDE so they don’t feel like they’re shut out of the development of a product that significantly affects them. If enough of this happens outside of KDE itself, we run the risk of the project being taken over by sheer weight of outside contributions by large companies.

This is why I feel so strongly that the KDE e.V. should start hiring community members for technical roles. With the KDE community itself clearly in charge of the gravitational center of paid engineering, these outside companies would find it more convenient to simply pay money to the e.V. to strengthen those development efforts, join a sort of technical advisory board, or pay for priority access to engineering resources to fix bugs affecting them (not features, only bugs). These could give those companies the the “seat at the table” that they’re looking for while keeping technical decision-making firmly in the hands of the community. The project would be able to remain independent more easily.

It’s not a problem we urgently need to solve right now, but it will be in the future if we’re as successful as I want us to be. I think it behooves us to do it now rather than later.

Hire Geeks, not Mops

Whenever someone is paid to work on KDE stuff–either by the KDE e.V. or anyone else–always prioritize hiring KDE community members over outsiders. There’s always the risk that the outsider is a Mop who just wants a paycheck rather that someone who truly believes in KDE. Those with the privilege of being paid to work on KDE stuff should be people who go above and beyond because they love it.

Foster a culture of resistance to Sociopathy

KDE will probably never be an institution where you can get rich quick, and I see this as a good thing. But not all Sociopaths are in it for the money; some crave power. An important project like KDE will still hold appeal for the type of Sociopath who wants to push everyone around as the king of a little digital fiefdom. We need to keep these people out.

Unfortunately, while Geeks are generally good at noticing when Sociopaths show up, they are generally terrible at kicking them out. Geeks can be conflict-averse, or believe that the Sociopaths can be reasoned with, reformed, or safely tolerated because they do some good work. They cannot be.

KDE needs to maintain and expand a culture of resistance to Sociopathy by teaching its members to harden themselves against Sociopaths and and use some of their own tactics against them when they show up. Nobody should be the king of KDE. KDE should not have a king! Central leadership is a risk factor, as I blogged about earlier.

What it all looks like

KDE will attract as many Geeks as possible through our continued commitment to technical excellence and supporting power user workflows in our software. We minimize the risk of demanding Mops burning everyone out by not selling anything to them directly and maintaining a favorable Geek:Mop ratio through our attraction of lots of Geeks. We start paying for engineering talent, but we hire insider Geeks, not outsider Mops. And we do it within KDE itself. Then we remain vigilant for Sociopaths craving power, and we kick them out so that KDE can remain a safe place for the Geeks.

So who’s ready to take over the world with love and positivity and user-empowering high quality software?

Lenovo ThinkPad X1 Yoga: impressions, bugs, workarounds, and thoughts about the future

My new laptop arrived last week and I’ve been using it since then! Here are my impressions so far of the Lenovo ThinkPad X1 Yoga (gen 4), and how it compares to my old laptop, a 2016 HP Spectre x360:

Hardware side

Case and ports

Top-notch quality. The laptop feels lightweight given its size, and it is very rigid. I had worried that the dark aluminum case would show fingerprints, but it’s not a problem. Port selection is generous: 2 USB-C+Thunderbolt+charging ports, 2 USB-A ports, an HDMI port, and a combo audio jack. Perfectly sufficient for my purposes, and better than the laptop it replaced! I do wish the USB-C ports were more snug, though. USB-C cables tend to wiggle around when plugged in. Also it would be nice if the lid could be opened with one hand, but that’s a very minor nitpick. Overall it is solidly better than my old laptop.

Screen

The Thinkpad X1 Yoga’s 4K screen is unbelievable. Color reproduction is excellent, there is no significant ghosting, and brightness goes high enough to use it outdoors without limitation. I turn the brightness down to 50% when using it indoors. It’s by far the best screen I’ve ever had the pleasure of using, and a huge upgrade over my old laptop!

Keyboard

The keyboard feel is perfect; typing on it is a dream! And its black keys contrast perfectly with the white backlighting to produce a good low-light typing experience too. However the layout of the keys presents a few annoyances that I’m having to get used to:

  • Left Fn and Ctrl keys are reversed compared to every other PC laptop keyboard. This can be changed in the BIOS, but then the labels don’t match the functionality, which is somehow even more confusing.
  • The PrintScreen key is located between the right Alt and Ctrl keys, and I find myself constantly pressing it when I mean to press the right Alt key, especially to hit Alt+Left to go back in Dolphin or Firefox. Seems like a weird place to put it.
  • The Home and End Keys are located up at the top of the keyboard, away from the arrow keys. I find myself wishing they were in a column at the right side of the keyboard as on my old laptop, where they were easier to press without changing the positioning of my right hand which often hovers around the arrows.
  • There are no dedicated media playback keys. This is not a major issue as I have mapped Alt+Ctrl left/right/space to those functions in Plasma’s shortcuts KCM. Still, I do miss the dedicated keys.
  • Toggling the keyboard backlight is done with Fn+Space, rather than a dedicated key. Also the multi-level brightness feature seems kind of superfluous. Simple on/off modes would be better IMO. Not really a big deal though.

Overall, compared to my old HP Spectre x360 laptop, I would say I prefer the typing feel and black key color of the Lenovo’s keyboard, but prefer the key layout of the HP’s keyboard.

Touchpad

The touchpad is perfect. It’s just the right size: not too big, and not too small. The glass-covered surface makes it a pleasure to use. With the Libinput driver, thumb and palm rejection are perfect, enabling my favorite way of using a touchpad: with my right thumb lazily resting at the bottom as if there were a physical button there. I click with the thumb and use the rest of my fingers to move the cursor or perform scrolling gestures. This is how I got used to using Mac touchpads back when I was an Apple user and the Lenovo’s hardware is good enough to replicate that. It’s not quite Mac quality, but I’d say the experience is 90% there. It’s really, really good, and a huge upgrade from my old laptop whose trackpad was a bit worse in almost every way.

Speakers

The speakers sounded great in Windows during my initial test so I know that the hardware is quite capable. However, on Linux the sound is not so good, and more work is needed on the driver side. So at the moment, the speakers are a disappointment and a regression compared to my old laptop, but hopefully improved audio drivers will make them better in the future.

Camera

The camera is horrible, which is an unwelcome surprise for this very expensive computer. Its resolution is a very low 720p, and there is noticeable lag/latency, which makes video conferencing annoying for other people as my mouth does not match my words. This is a significant regression compared to my old laptop, which had a 1080p camera with no appreciable lag. I didn’t test the camera in Windows before installing openSUSE Tumbleweed, so I don’t know if the lag is a hardware limitation or a driver bug.

Software side

On the software side, things have not been as good.

Installing openSUSE Tumbleweed was not too big of a hassle, given that I’ve done this a number of times before. I had to disable secure boot, which entailed a trip to the BIOS and bricking Windows. After installation, a number of local workarounds were required to make things function, in particular the audio, which still does not seem to be working properly. Just check out the relevant Arch Wiki pages! That’s a lot of stuff that you need to fix manually. After the OS was installed, I started to run into other issues:

Speakers and sound

Initially, the speakers were not detected at all. The relevant Arch Wiki page was very helpful here: installing the sof-firmware package fixed that, but then the audio quality was horrible. Compiling PulseAudio from source to get version 14 (which is not released yet) made it better, but still not as good as it was on Windows. I have filed a bug on PulseAudio as it seems like more work is needed: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/914

Also, there are pointless devices corresponding to the three HDMI/DisplayPort audio outputs, which should not be shown unless they’re actually in use. This affects both the Plasma audio applet as well as the Pavucontrol app:

It’s not totally clear to me whose fault this is, so I filed a bug on PulseAudio and also one on plasma-pa. We may be able to improve the display in Plasma at least, and I’m working on a merge request.

Power management

Battery life is poor. This laptop has a 51 watt-hour battery (up from 42 Wh on my previous laptop), but draws between 8 and 10 watts at idle. When actually using the machine, I’m only getting about 4 hours of battery life! Reviewers said that it got at least 7 hours in Windows, so this is pretty terrible. powertop reports that the display backlight uses 10 watts of power at full brightness, 5 watts when at its lowest level, and 4 watts when turned off entirely! And the bottom of the case is always warm, so perhaps the CPU is also not idling enough. So I suspect that there are some performance and power management bugs somewhere, as this level of power consumption does not seem expected, even with the 4K screen. On the plus side, at least the laptop charges very quickly with the included 65W charger. :/ I have not filed any bugs on this particular set of issues yet as I’m not suite sure where to start.

Touchscreen

Out of the box, the touchscreen did not work properly on X11 with Plasma, KDE apps, and other Qt apps–but it did work with GNOME and Electron apps! After filing a bug report on Qt, I discovered that switching to the libinput driver fixes the issue! To do this, you can uninstall the xf86-input-wacom package (which will also remove the Wacom page in System Settings, which may be undesirable if you’re using it) or alternatively you can apply the following patch to /usr/share/X11/xorg.conf.d/70-wacom.conf:

diff -rubd /usr/share/X11/xorg.conf.d/70-wacom.conf.orig /usr/share/X11/xorg.conf.d/70-wacom.conf
--- /usr/share/X11/xorg.conf.d/70-wacom.conf.orig       2020-06-08 08:08:01.576986784 -0600
+++ /usr/share/X11/xorg.conf.d/70-wacom.conf    2020-06-08 08:07:04.624218429 -0600
@@ -19,7 +19,7 @@
         MatchUSBID "056a:*"
         MatchDevicePath "/dev/input/event*"
         MatchIsTouchscreen "true"
-        Driver "wacom"
+        Driver "libinput"
 EndSection
 
 Section "InputClass"
@@ -43,7 +43,7 @@
        MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
        MatchDevicePath "/dev/input/event*"
        MatchIsTouchscreen "true"
-        Driver "wacom"
+        Driver "libinput"
 EndSection
 
 Section "InputClass"

Ubuntu has already made a similar change to their packaging and I filed a bug report for openSUSE as well: https://bugzilla.opensuse.org/show_bug.cgi?id=1172669.

Next up, touch scrolling did not work in Firefox. I already knew how to fix this, and I’ll teach you too:

  1. Add MOZ_USE_XINPUT2=1 to the /etc/environment file. This turns on touchscreen scrolling and enables pixel-by-pixel touchpad scrolling.
  2. Doing the above triggers a nasty bug that breaks scrolling when a notification appears, but you can work around that as follows: Open System Settings > Window Management > Window Behavior > Uncheck “Click raises active window”.

Obviously we should just fix the KWin bug that makes this workaround necessary. We eventually will!

After this, touch input works well, especially for GTK apps. We have a lot of work to do to make our own KDE apps work as well with a touchscreen as GTK apps do on average.

Broken Flatpak apps

I briefly encountered an issue where none of my Flatpak apps would launch:

$ flatpak run com.discordapp.Discord
Gtk-Message: 07:05:34.667: Failed to load module "unity-gtk-module"
Gtk-Message: 07:05:34.667: Failed to load module "canberra-gtk-module"
No protocol specified

(Discord:4): Gtk-WARNING **: 07:05:34.667: cannot open display: :99.0
[fake-sandbox: zypak-sandbox] No data could be read (host died?)
[fake-sandbox: zypak-sandbox] Quitting Zygote...

This utterly bizarre issue turned out to have been caused by me setting the computer’s hostname incorrectly, using sudo hostname <new hostname> instead of sudo hostnamectl set-hostname <new hostname> which triggers an SDDM bug which is fixed by the following open pull request: https://github.com/sddm/sddm/pull/1230. Hopefully the SDDM bug will be fixed soon, and in any event I should just add a GUI method of setting the computer’s hostname which I’ve been meaning to do for a while. See https://bugs.kde.org/show_bug.cgi?id=259285.

Scaling issues in Plasma

On X11, Plasma did not auto-detect that I was using a 4K screen, so I had to manually change the scale in the KScreen KCM. Then I had to manually sync that to SDDM in the SDDM KCM to make the login screen not look tiny. It would be nice if the appropriate scale factor would be autodetected, at least for 4k screens. I have filed https://bugs.kde.org/show_bug.cgi?id=422552. Happily, this already works out of the box on Wayland! So go Wayland.

In addition, once I did set a 200% scale factor, all the icons in Plasma looked tiny, making everything hideous. This is https://bugs.kde.org/show_bug.cgi?id=356446, and I worked around it by setting PLASMA_USE_QT_SCALING=1 in the environment, which fixes the issue and makes Plasma look fantastic at 200% scaling. However it also makes the minimize animation zoom into the wrong location. Boooo! As before, all this stuff works out-of-the-box on Wayland. Hmm…

Once I had the scale properly set, I noticed that various UI elements were not automatically scaled:

The first three actually work fine on Wayland! So I’m getting the sense that I should just bite the bullet and use Wayland, since the high DPI behavior is much better.

Next, I incrased the scale to 250% to make everything a bit bigger, and then various icons that are supposed to be monochrome became colorful. This is a minor issue, but I’ve submitted a patch to fix it: https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/3

Anyway, other than these issues, scaling works great. We’re pretty close, I think.

Conclusion and the future

I wish I could say that it’s been a pleasant, trouble-free experience and that I’m loving my new computer. In truth, getting the ThinkPad X1 Yoga to function well enough to comfortably write this post took several frustrating days of poring over documentation, filing bug reports, tweaking config files, and altering kernel parameters. On top of that, it’s still not quite there yet and is worse than my old laptop in several ways despite costing twice as much money. The high DPI scaling issues are our fault in KDE, and we need to do better, but that’s just the tip of the iceberg. The problems run throughout the entire software stack. Simply put, this is not acceptable in 2020. We need to up our game of partnering with hardware makers to ship FOSS operating systems by default. Everything I’m going through with this computer is the kind of problem that should be caught by paid Linux QA teams so that it can be fixed before the hardware is released to customers.

I continue to believe that we will get nowhere until more hardware comes with a Linux-based OS pre-installed. People shouldn’t have to deal with this kind of nonsense! My wife has been happily using KDE Neon on her laptop for two years, but I had to do the initial installation. Normal people want their computers to just work, not endlessly fiddle around with settings to make things functional that should have been so out of the box in the first place.

Part of me wishes I had instead gone with the SlimBook Pro X 15 or the System76 Lemur Pro, which were strong contenders in my search. The SlimBook laptop can even be pre-installed with Plasma-bearing operating systems like KDE Neon and Kubuntu, and I’m sure the System76 folks would have done likewise had I asked nicely enough. Everything would have worked perfectly out of the box, because SlimBook and System76 have QA teams paid to do what I’ve been doing myself for the ThinkPad X1 Yoga. Alas those laptops didn’t have some of what I was looking for in the hardware department (principally touchscreens and higher quality speakers), but perhaps I was underestimating the importance of integration into a cohesive product. It certainly stands in stark relief right now.

I’m sure things will get better over time. Kernel fixes will accumulate, and the bug reports I’ve filed will start to get fixed. I may even fix some of them myself. But this state of affairs is simply not acceptable if we ever want to grow our audience beyond the ranks of tech nerds. No normal person spends over than a thousand dollars on a laptop for real productive purposes that will have to become an extended science experiment before it works properly. We need more hardware sold with our software pre-installed, period. That’s the next frontier, and I strongly believe that we need to make it our end goal for everything we do.

KDE roadmap for 2020

Yesterday I summarized some of my favorite new features, both big and small, added to KDE’s software catalog in 2019. Today I’d like to talk about the major features and improvements I expect for 2020. Note that this is not an official planning document, it’s just what I anticipate happening and plan to push for and help implement. Without further ado…

Guaranteed

These features are pretty much guaranteed, as they’re almost done or even in the process of landing:

FUSE mounts to better support accessing remote locations in non-KDE apps

Not mounting remote locations has been a longstanding deficiency in the KIO library that does file I/O throughout KDE software. Without this feature, users of non-KDE 3rd-party apps experience frustration when opening large files or streaming videos located on remote locations, when saving changes to those files, and when trying to to File > Save As to make a copy alongside the original.

Throughout much of 2019, a FUSE mount solution has been in development that alleviates these issues! You may have read it about on the blog of Alexander Saoutkin, one of the principal developers working on the feature.

A truly enormous amount of work has already been done, and at this point only a few more bits are needed before we can formally roll it out:

  1. KIO::Open support in KIO-FUSE itself
  2. File truncation support in KIO to support true random-access reading
  3. Adoption of this file truncation support for Samba and SFTP protocols
  4. On-the-fly translation of network URLs into FUSE paths to ensure seamless mounting of accessed network resources

When the patches for these improvements land, we will have full feature parity with the FUSE-based GVFS system that GNOME uses and the mount-based system in macOS! The patches are in progress and I expect them to all land in the next two or three months.

Privilege escalation in KIO and Dolphin

I’ve been promising this for years, talking about how it’s 90% done, then 99%, then 99.9%… you get the idea. I know, I know, I’m the boy who cried wolf at this point! Well, this time we really are on the cusp of victory. There is only a single patch left before we can formally turn it on! Once this happens, you will finally be able to create, move, rename etc. root-owned files in Dolphin without needing to run Dolphin as root or using a hacky extension.

Improved Samba share discovery in Dolphin

We have a patch that implements the WS-DISCOVERY protocol in Dolphin, allowing it to find Windows Samba shares on your local network, which are currently invisible. This has been a longstanding problem, but it’s now finally getting fixed! I expect this patch to land in the next few months, in time for Dolphin’s 20.04 release.

Auto-rotation for tablets, convertibles, and other hardware with rotation sensors

There’s an absolutely enormous patchset that implements this much-awaited feature. More than half of the patches have already landed, so the rest aren’t far behind. I have my doubts that this will make it into Plasma 5.18, but 5.19 is almost certain.

Likely

These features are likely, but not guaranteed:

Implement more of the proposed visual design changes to the Breeze style and KDE apps

The KDE VDG now has an exhaustive plan and sets of mockups for how we’d like to evolve Breeze, Plasma, and KDE apps in the near future: https://phabricator.kde.org/T10891. Check out the dependency graph! Here are some examples:

Pretty hot stuff, huh!?

Bits of it are already getting done. In 2019, we completed a UI overhaul of Plasma and many apps’ configuration windows to use the Form Layout style and a sidebar UI redesign, both of which have been quite well received. And there’s a new SimpleMenu based on VDG mockups in the works, which we hope to replace Kickoff as the default.

I don’t know if everything here will get implemented, but I expect us to push forward with a lot of it!

Better wallpapers in the extra wallpapers repo

A lot of the wallpapers in the plasma-workspace-wallpapers repo (which is optional but installed by default in many KDE distros including Neon, Kubuntu, and Manjaro) are a bit long in the tooth. Thankfully, we have a patch queued up and ready to go that will replace them with modern, beautiful, 4K wallpapers. Unfortunately this patch is blocked by the lack of a wallpaper cache, which means if we replace a wallpaper that someone is currently using, they’ll see a black screen after they upgrade. Not very nice. We’d like to cache the current wallpaper so that this doesn’t happen. I’m hoping we land the cache feature early in 2020 so that the next Plasma release after it can get the improved wallpaper selection.

Moonshot

These features are less likely (bordering on unlikely), but could get in with enough development work!

Per-screen scale factors on X11

There’s a patch implementing this feature that has been rejected thus far because it was not technically correct with the way Qt handled scaling at the time. However Qt 5.14 implements some backend changes that would appear to make this possible. I can’t promise anything but I plan to investigate this to see if it’s something we can do once Plasma depends on Qt 5.14, or if it’s feasible to add the feature earlier than that with a bunch of ifdefconditionals in the code to only turn it on for people using Qt 5.14.

Inertial scrolling throughout Plasma and QML apps

In theory, this is easy-ish. In practice, there are a lot of moving parts. Preliminary work began a few weeks ago, but there’s a lot to do before we can make it all work. It’s on the workboard though!

Power/session controls on the lock screen

This is something needed for Plasma Mobile, and all the Plasma developers agree that it’s fine to have on the desktop too. Development has not yet started, but it might!

What do you think? Seems like a bunch of worthwhile stuff, right? I see these features and improvements as critical for my ultimate goal of making Plasma and KDE apps irresistible for hardware vendors to ship by default (most of them at least; better wallpapers are nice but not critical). I want to make our offerings so good, and for KDE in general to be such a good upstream, that companies trip over each other to put Plasma and KDE apps on their devices! I think ultimately that’s the best way to get our software in front of more users.

If this sounds exciting to you, please feel free to help out–especially for items in the “Likely” and “Moonshot” lists, which are less certain to happen without help. You can help out by testing patches, implementing mockups, hacking on the new features, etc. For more information, visit https://community.kde.org/Get_Involved. It’ll be interesting to check back at the end of 2020 to see how many of these projects have been completed. With your help… hopefully all of them!

2019: the year in review

2019 was a massive year for KDE. I’d like tho take the opportunity to highlight some of the biggest improvements and new features that arrived in this year:

Wayland

Though Plasma-on-Wayland is still not totally ready for prime time (and I understand now annoying this is), we made steady progress toward that goal, knocking out a number of blockers. 2019 featured Wayland support for virtual desktops, the proprietary NVIDIA driver, fractional scale factors, screen sharing and remote desktop, Spectacle’s Rectangular Region mode, and the Plasma widget explorer!

Plasma

One of the Plasma highlights this year is the totally rewritten notification system with a Do Not Disturb mode, per-app notification preferences, a sane history model, and loads of refinement and polish. It’s amazing, and it keeps getting better with each Plasma release!

Also very impactful has been a set of improvements in support for client-side-decorated GTK3 apps, including including shadows and extended resize areas and following the system’s color scheme. GNOME apps now look and feel right at home in Plasma!

Plasma also gained a systemwide Emoji input panel and a touch-friendly global edit mode for widgets. This allowed us to delete the Desktop Toolbox–that mystifying hamburger menu in the corner of the screen. Poof, no more!

In System Settings, there is finally full support for configuring touchpads using the Libinput driver, the Night Color feature was ported to X11, and the Workspace Behavior page gained two useful new controls that let you change the speed of all animations through Plasma and apps, and configure what happens when you click in a scrollbar track. In addition, many System Settings pages–particularly those in the Appearance section–have been modernized and given consistent user interfaces.

There were also many improvements to wallpaper configuration. The configuration window now displays the actual set of images that will be used, and the order is configurable. Picture Of The Day wallpapers can now pull images from unsplash.com.

To protect your privacy, Plasma now alerts you when an app is using the microphone.

Discover’s user interface and reliability dramatically improved across the board. I’m no longer seeing social media posts about how much people hate Discover (at least not the latest version; please make sure you’re up to date before you complain!). 🙂

Other miscellaneous features include a configurable grid size for desktop icons, user-customizable date display in the Clock widget, the ability to do calculation and unit conversion from Kickoff, and using slight RGB font hinting by default.

Finally, it became much easier to test and use a compiled-from-source Plasma version. Thanks to this, I’m now living on the master branch of Plasma all day, every day! It’s ridiculously stable, a testament to the incredibly high quality of Plasma’s codebase.

Applications & Frameworks

KDE’s flagship apps gained many amazing and useful new features. Among them:

Dolphin and file dialogs

Dolphin gained support for showing file creation dates, a feature to open folders from other apps in tabs instead of new windows, navigation history in a drop-down menu when you click-and-hold on the back or forward arrows, and animated previews in the Information Panel for video files and animated image files like GIFs. It also tells you what’s blocking unmounting a volume that contains open files, shows tags in the Places panel sidebar, and lets you search for tags.

Dolphin and other KDE apps gained file previews for Blender files, eBook files, .xps and Microsoft Office files.


Dolphin and the file dialogs also gained human-readable sort order descriptions and a brand new much better recent Documents feature.

File dialogs now let you easily switch between the same view modes as in Dolphin, and drag-and-drop a file into the main view to select that file or switch the view to that file’s folder (depending on whether it’s an open dialog or a save dialog).

Gwenview

Gwenview gained High DPI support, touch support, and a JPEG save quality chooser.

Spectacle

Spectacle gained the ability to open new instances or switch to existing instances when pressing the PrintScreen key while already running, configure its global keyboard shortcuts from its settings window, always copy a just-taken screenshot to the clipboard, auto-accept the dragged box in rectangular region mode, and remember the last-used rectangular region box. Rectangular Region mode also became touch-friendly.

Okular

Okular gained smooth scrolling and inertia with touch swipes, support for viewing and verifying digital signatures, and the ability to navigate both backwards and forward in touch mode. It also now remembers view mode, zoom settings, and sidebar view settings on a per-document basis.

Kate

Kate gained an LSP client, regained its old External Tools plugin, got the ability to show all invisible whitespace characters, and massively improved support on High DPI systems, particularly when using a fractional scale factor.

Konsole

Konsole got a tiling split view mode with drag-and-drop re-ordering:

Elisa

The Elisa music player gained an enormous amount of user interface polish, new features, and bugfixes–too many to list, really. It’s a powerful and user-friendly music player that’s fully supported and actively developed, and I encourage everyone to use it! Kubuntu is evaluating shipping it by default in their upcoming 20.04 release, and I hope others follow suit.

This is only a small subset of the new features announced throughout the year in my Usability & Productivity and This Week in KDE series, which in turn are small subsets of the full range of work done throughout KDE. Truly, our community is blessed with tireless contributors! Looking forward to 2020, I think we’re poised to achieve some truly amazing things that will catapult KDE Plasma and apps to the forefront of the Linux world. More on that tomorrow… 🙂

Legislating is patch review

Patch review is a process by which newcomers and experts debate proposed changes to a codebase–a textual description of how a particular human-created system is to function. In KDE, we use Phabricator for this, but we’re switching to GitLab soon. Both serve the same purpose: to provide a forum where proposed changes can be discussed, revised, and decided upon.

It occurred to me recently that this sounds a bit like the process of lawmaking. Politicians propose bills (patches) that amend their government’s code of laws (codebase) which are passed through committees and hearings (the review process) and eventually get voted on (reviewed) and either pass (get merged) or require revision (go around for updates), or fail (get abandoned).

Pictured: typical 18th-century patch review process

I’m reasonably confident that there’s little overlap between politicians and software enthusiasts. In my home country of the USA for example, most of our federal government politicians are former lawyers, businesspeople, or educators. “Software engineer” is listed as a “more unusual” former profession.

This strikes me as a shame. While lawyers, businesspeople, and educators are quite unfamiliar with the process of transforming a proposal for improvement on a systemic scale into a permanent alteration of the rules that affects everyone, software people do it every day. Likewise, software people like us tend to have little experience in the political process. We act like we invented patch review, but our governments have been doing it for hundreds of years! The overlap got me thinking: perhaps there is something that each group can learn from one another.

 

Have a constitution

Governments write constitutions to make their foundational principles clear and obvious. That way, everybody knows which ideas are central to the society’s identity, and which ones are off-limits.

Lesson for software engineers: Make your software’s guiding principles, explicit, not implicit. People often figure this out organically, but it’s much easier if your software has a constitution-like document and clearly indicates which features are non-negotiable when it comes to proposing their implementation or removal.

 
 

Don’t neglect trust

If you have a bad relationship with the people reviewing your patch, they will suspect your motives, nitpick your changes, and generally react with low enthusiasm. Even if your patch is a good one, the reviewers’ opinion of it will be clouded by their judgment of you. Therefore, don’t neglect your social relationships and act like a jerk, or else the whole process basically doesn’t work.

Lesson for politicians: don’t ignore or damage your social relationships with your colleagues or else your entire job is a big waste of time. Adopt a mindset that legislation is a collaboration rather than a majority-rules deathmatch or an opportunity to make speeches on a stage. Also, arrive with pure motives. If you’re there to try to tilt the playing field towards your favored groups, the people who represent the opposite side will notice and oppose you at every turn, and you’re likely to have a frustrating and unproductive career full of outrage-filled press conferences but not much real accomplishment.

 
 

Review in stages

In governments, often bills undergo review by multiple committed before they’re presented to the full body for debate and voting. This is good, because it gives a chance for obvious mistakes to be corrected in advance of the final vote.

Lesson for software engineers: use a multi-step patch review process, with relevant experts in control at each step of the way. For example, the big-picture software architects should review a patch for to make sure it conceptually makes sense in the first place; then backend programmers should dive into its technical implementation; the UI designers should go over its user interface, and so on.

 
 

Keep patches small

Large patches are hard to review and fill the reviewers with a sense of dread. They touch many things and therefore have more opportunities to change something in a way that a stakeholder will object to. They often get bogged down in process and conceptual arguments. For these reasons, it’s best to keep patches small and focused, and split a large change into a series of individually-manageable patches that each depend on one another, known as a dependency chain.

Lesson for politicians: avoid 1,000 page mega-bills. If a bill needs to be enormous in order to work, there’s probably a deeper conceptual issue with it that everyone senses.

 
 

Have an institutional memory

Records of how bills are moved along in the lawmaking process are kept meticulously. This preserves institutional memory, so that newcomers don’t make the same mistakes that their older colleagues and forefathers already learned from.

Lesson for software engineers: Keep records of why decisions were made–and even more importantly, why they were reverted. If you move from one infrastructure system to another, migrate all the data so history isn’t lost. This prevents the phenomenon of newcomers who propose the same changes and repeat the commit/regress/revert cycle.

 

Make reversion easy

When a patch causes regressions, it can be reverted. Oftentimes it’s better to fix it, but if the fixes are too invasive or the regressions outnumber the benefits, it may be a better idea to revert the change and try again. Making reversion easy promotes a culture of innovation and experimentation. People won’t be as worried about merging things, because if they cause problems, it’s easy to undo the changes. Change becomes playful and fun, rather than consequential and scary.

Lesson for politicians: Don’t make it too hard to repeal bad laws. When a newly-passed law causes problems in a society, it’s tempting to try to amend it to fix the problems, and sometimes this works. But sometimes it just needs to be re-done from scratch, like a bad patch in software. Being willing to repeal laws that aren’t working defuses tension. That said…

 

Don’t rush

Bills and patches that get through their processes quickly are often problematic, riddled with unseen regressions and unanticipated consequences. This is much less common in governments, because the lawmaking process usually has deliberate safeguards put in place to ensure that a bill is not transformed into a law too quickly before there’s been adequate time for debate.

Lesson for software engineers: Take your time so you don’t push out buggy, regression-filled software. However…

 
 

Don’t make your users live on the master branch

Rushing isn’t such a huge deal as long as you have a QA process and discrete releases. These tools provide time for regressions to be fixed and rough edges to be smoothed out. When patches can be evaluated in a safe sandbox of sorts and subsequently tweaked before their effects are released to users, it’s not so bad to move quickly. But you can’t expose your users to the churn stirred up by a fast process; it needs to be contained internally.

Lesson for politicians: You don’t need so much process surrounding lawmaking if you don’t roll out all approved changes immediately. Before new bills take effect, let them simmer for a while in a “release branch” where they can undergo QA so that regressions can be found before they’re inflicted on unsuspected citizens (users)!

 

As software people, there are lessons we can take from our governments’ successes (and more often these days it seems, their failures), because this aspect of our professions overlaps quite a bit. It also exposes an uncomfortable truth: changing the rules and behaviors of a system that effects everyone is inherently political. That’s why we invented patch review processes: to make sure that important voices are heard, that the system doesn’t become inhumane for people who depend on it, and that its overall trajectory is positive.

Personally I’m a lot more sanguine about the prospect of this in software than government right now, and I think that’s something that needs to change. The efficacy and positive societal impacts of our governments’ lawmaking seems to be at a bit of an ebb at the moment. But there may come a point in time when our experience in patch review becomes useful on a larger stage, and benefits not only users of KDE software, but also the people of the world. We shouldn’t be afraid of politics; our everyday experiences in KDE are in fact the prefect preparation! Far from being distant and scary, it’s something we’re engaging in–and succeeding at–every time we contribute to KDE. I think it’s time for us to become active in applying those lessons to the societies that we live in.

KDE Usability and Productivity: Are we there yet?

KDE’s Usability & Productivity initiative is now almost two years old, and I’ve been blogging weekly progress for a year and a half. So I thought it would be a good time to take stock of the situation: how far we’ve come, and what’s left to do. Let’s dive right in! Here’s a short list of some of the achievements we’ve accomplished:

  • Full support for configuring mice and touchpads using the Libinput driver on both X11 and Wayland
  • A brand new notification system with hugely improved usability for common workflows
  • Better default text contrast and font rendering settings
  • Massive, far-reaching user interface and performance improvements for Discover
  • Huge user interface improvements to the open/save dialogs
  • Many performance and reliability improvements for the Baloo file indexing service
  • “Open Containing Folder” actions added throughout KDE apps
  • A variety of usability-related bugfixes, new features, and user interface upgrades for Spectacle
  • Typewriter/text box annotation tool in Okular
  • Support for showing file creation dates
  • Easy support for file tagging in Dolphin, and a more useful and comprehensible Places panel
  • Slideshow wallpaper configuration that shows the actual images that will be a part of the slideshow
  • Configurable grid size/maximum label width for files and folders on the desktop
  • Better lock and login screens
  • Consistent styles (grid views and centered form layouts) for settings windows throughout KDE software
  • Simplified and more comprehensible user interface for many System Settings pages
  • Bugfixing and user interface improvements throughout the whole software stack

It’s a lot of great stuff!

There’s still more to do, of course. KIO still doesn’t mount network locations locally, though that’s being actively worked on! Touchpad scrolling behavior has improved, but is still not consistent across all KDE apps and there’s no inertial scrolling yet. Samba sharing is improving, but still rough. Okular’s annotations are becoming more full-featured, compatible, and discoverable, yet more work is still needed. More System Settings pages still need to have their user interface overhauled. But are you seeing a pattern here!? Things are happening! The trajectory is really good! It’s unbelievable how many of the rough edges have gotten smoothed out over the past two years, and I feel super upbeat about the state of KDE’s software offering!

With this kind of ongoing work, KDE’s software moves ever closer to the day when I envision that it has become humanity’s preeminent computing platform. It will take time, but open-source software is immortal as long as people care about it. And the KDE community clearly does! So slowly but surely we continue, improving year by year as competitors stagnate, drop out, or are corrupted by the lures of money and power. It will be a KDE world.

Author: opekope2, KDE community member, from our recent wallpaper competition: https://forum.kde.org/viewtopic.php?f=312&t=160543

I’d like to offer a congratulations to the incredible KDE community. This all is not my work… it’s yours! The passion that people feel for this stuff is amazing, and it’s not misplaced: more and more KDE software becoming best-in-class in its product category. The future is bright, very bright. Thanks again, everyone.

Interview on Linux Unplugged podcast

A few days ago Jupiter Broadcasting’s Chris Fisher approached me about doing an interview for his Linux Unplugged podcast, so I said sure! I talked about the Usability & Productivity initiative, Kubuntu and KDE Neon, my history at Apple, and sustainable funding models for open-source development.

Awesomely enough, it turns out that their systems all run Kubuntu 18.04, and Chris calls it “the best distro we’ve ever used in production.” Now that’s what I like to hear! It’s exactly what the Usability & Productivity initiative is all about: making KDE software a lean, mean, productivity machine for creators and professionals.

You can listen to the show here: https://linuxunplugged.com/268. My segment starts at about the 25 minute mark.