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.

This week in KDE: Okular, Konsole, Plasma, and Wayland

It’s early in the Plasma 5.20 development cycle and some very nice new features landed this week! Various KDE apps–in particular Okular and Konsole–also got new features. It’s a feature-palooza!

Yes, yes, I know what some of you are thinking: “Why are you writing new features while there’s still so much buggy stuff?” In this case, one of the answers is that new features can often solve bugs. For example the Okular work you’ll read about below resulted in a dozen bug reports getting closed! Sometimes you really can have your cake and eat it, too. 🙂 And of course the Wayland work continues as well…

New Features

Okular’s annotations toolbar has been completely re-done and is now much more discoverable and easier to use! This improvement has been in development for over a year and I’d like to call attention to Simone Gaiarin for his tremendous work here! (Simone Gaiarin, Okular 1.11.0):

Konsole now shows you a thumbnail preview for image files that you hover your cursor over by default (Tomaz Canabrava, Konsole 20.08.0):

Middle-click paste now works on Wayland! (David Edmundson, Plasma 5.20.0)

Changing the screen brightness now smoothly animates the transition rather than jumping from one brightness level to another (Kai Uwe Broulik, Plasma 5.20.0)

It’s now possible to adjust the balance of individual elements of your speakers (Kai Uwe Broulik, Plasma 5.20):

File choosers displayed by Flatpak apps now implement the ‘choices’ element of the filechooser spec and can therefore be given custom views from the app itself (Michael Weghorn, Plasma 5.20.0)

The Web Browser widget now has a user-configurable zoom setting (Sora Steenvoort, Plasma 5.20.0):

The touchpad cursor speed setting can now be configured on a much more granular basis if desired (Giusy Margarita, Plasma 5.20.0):

Bugfixes & Performance Improvements

Dolphin now shows progress notifications for duplicated files when the duplication takes more than a moment (me: Nate Graham, Dolphin 20.04.2)

When using an alternative input method, Konsole now shows the input method window right below the cursor, where it’s supposed to be (Fuminobu Takeyama, Konsole 20.08.0)

Spectacle no longer gets killed when the notification displayed for the last screenshot disappears (Méven Car, Spectacle 20.08.0)

KRunner’s window now appears in the right place when using a top panel on Wayland (Benjamin Port, Plasma 5.20)

Folder previews no longer allow the embedded thumbnails to overflow out of the view when they’re very very tall or very very wide (Méven Car, Dolphin 20.08.0)

Dolphin’s free space bar is now correctly sized no matter your font settings (Ahmad Samir, Dolphin 20.08.0)

Yakuake no longer unconditionally switches terminals when Shift+Tab is pressed, unless you actually set that as a keyboard shortcut (Maximillian Schiller, Yakuake 20.08.0)

User Interface Improvements

Okular’s main window has received a visual overhaul, resulting in a new default toolbar layout and hiding the page bar at the bottom of the window by default (me: Nate Graham, Okular 1.11.0):

The Properties actions/menu items in Okular and Gwenview are now triggerable using the standard Alt+Return keyboard shortcut, just like in Dolphin (me: Nate Graham, Okular 1.11.0 and Gwenview 20.08.0)

Okular now makes it easier to see all of the page sizes in a document with more than one page size (me: Nate Graham, Okular 1.11.0):

It’s now possible to explicitly set the size of System Tray icons (Konrad Materka, Plasma 5.20):

KRunner’s recent documents feature now uses the same data store as everything else with a “recent documents” feature, making its results more consistent and relevant (Méven Car, Plasma 5.20)

The overwrite dialog now makes it clear when the to-be-overwritten file has a file size that differs by less than a kilobyte (Méven Car, Frameworks 5.71)

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

This week in KDE: all about the apps

This week we landed a lot of nice improvements for KDE’s apps, which I’ve highlighted below! Of course we didn’t forget about Plasma, so have a look-see:

New Features

Dolphin now lets you mount ISO images using a new menu item in the context menu (Kwon-Young Choi, Dolphin 20.08.0):

Konsole now lets you monitor a tab for the active process to complete (Will Westrop, Konsole 20.08.0):

Bugfixes & Performance Improvements

Improved search speed/performance in Okular’s sidebar (Ahmad Samir, Okular 1.10.2)

Fixed a very common Yakuake crash (Maximilian Schiller, 20.04.2)

Fixed a common crash in Konsole when right-clicking and using Qt 5.15 (Ahmad Samir, Konsole 20.04.2)

Gwenview’s touch gestures now work properly when using display scaling (Steffen Hartlieb, Gwenview 20.08.0)

Notes widgets placed in a panel now display the pop-up note if clicked on when all windows are hidden or minimized (Marco Martin, Plasma 5.19.0)

Clicking on the settings button for a notification now opens the Notification settings page with that particular app focused and visible (Benjamin Port, Plasma 5.19.0)

KRunner once again shows Firefox bookmarks (Alexander Lohnau, Plasma 5.19.0)

KRunner now does a better job of handling file paths beginning with a tilde (Méven Car, Plasma 5.20)

When using Dolphin to view the desktop using the special desktop:/ URL, the amount of free space is now correctly displayed in the status bar (Ahmad Samir, Plasma 5.20.0)

Dates displayed in the file overwrite confirmation dialog now respect the date formatting of your current locale (Méven Car, Frameworks 5.71)

Deleting files from a Samba share no longer displays a notification with an inaccurate number of deleted files (Kai Uwe Broulik, Frameworks 5.71)

User Interface Improvements

Okular’s sidebar user interface has been overhauled, with the result that it now takes up less horizontal space, is easier to show and hide quickly, has a more consistent appearance overall, and fixes many bugs (me: Nate Graham, Okular 1.11.0):

The default gesture for moving windows has been changed to Meta+click, to avoid conflicting with apps like Krita, Inkscape, and Blender which use Alt+click for their own usages. Tell all your friends and spread this information far and wide so people aren’t surprised! If you hate the new one and don’t use Krita, Blender, Inkscape, or another app which uses Alt+Click for something, you can of course change it back to Alt+click (Noah Davis, Plasma 5.20)

When dragging files from Dolphin (or elsewhere) onto the desktop, the files now end up at the location where you dragged them, rather than at the end of the last row (Radek Husek, Plasma 5.20)

The battery charge level icons displayed by the Battery And Brightness applet now reflect the current charge status more accurately (Daniel Roschka, Frameworks 5.71):
more accurate battery charge level icons

The standalone KRunner widget now closes the pop-up if you hit the Escape key while the text field is empty (Alexander Lohnau, Plasma 5.20)

When using an ultrawide screen wider than 21:9, the default horizontal panel now no longer spans the entire screen width, but rather remains at the size it would be on a 21:9 screen, horizontally centered. Also in this mode, notification pop-ups that are configured to appear close to the Notifications System Tray applet will pop up close to it rather than way far away in a corner of the screen (Kai Uwe Broulik, Plasma 5.20.0):

The new OSDs now show a percentage label for brightness and volume (me: Nate Graham, Plasma 5.20):

Screenshot_20200529_092619

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

Laptop update

Thanks to the KDE community, I’ve finally chosen and ordered a new laptop: a Lenovo ThinkPad X1 Yoga. People heavily recommended the X1 Carbon, which is essentially the same computer except less touch-focused. That led me to the Yoga which seems to fit the bill perfectly: in addition to the necessary touchscreen, according to reviews it has otherwise excellent screen characteristics, a perfect keyboard, great speakers, and a great trackpad. I also like the look and probable durability of the aluminum case. Though it’s not a Ryzen 4000-series laptop, CPU performance is still three times better than my current laptop, so I’m not complaining. Mine arrives in three weeks. Thanks again everyone!

This week in KDE: We have migrated to GitLab!

After years of using Phabricator, KDE has officially begun the migration to GitLab! So far we are using it for patch review, and developer task tracking will be migrated soon. We are still using Bugzilla for bugs and feature requests as migrating those functions to GitLab is a significant project in and of itself! Already the KDE community is enjoying GitLab’s smoother workflow; why not take advantage of this and submit a merge request? 🙂

But that’s not all: big changes for Plasma 5.20 have started to land too. It promises to be a very significant release! Check it out:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

KDE Software is made by people just like you, often on their free time! If you know a KDE developer, send them a kind note. Developers like to put on a logical face but they need love and care too, especially during trying times like these.

More generally, have a look at https://community.kde.org/Get_Involved to discover ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

“Why don’t you just fix [thing] already?”

The title of this post is a somewhat common gripe among users. Its obvious answer is that resources are limited and people were working on other things.

Duh! Not very helpful.

We need to dig deeper and find the implicit question, which is “Why wasn’t [thing that I care about] prioritized over other things?” This is a more accurate and useful question, so we can arrive at a more accurate and useful answer: because other things were deemed either more important or more feasible to fix by the people doing the work.

Why would other things be deemed more important? For bugs, it’s because they affect everyone and are trivially reproducible. The ones that get overlooked tend to be more exotic issues that are not easily reproducible, or only affect niche use cases or hardware. Put bluntly, it’s appropriate that such issues are de-prioritized; it should be obvious that issues which affect everyone and are trivially reproducible are more important to fix.

Let’s step back a moment: in my experience, this is exactly the same as in closed-source software companies. Every piece of closed-source software has multi-generational bugs, baffling mis-features, and things that make you wonder, “jeez, why didn’t they fix this years ago?” Anybody who uses Windows, macOS, Android, or iOS can rattle off half a dozen examples instantly. So it’s not like FOSS is especially bad here.

Still, it’s still not a very satisfying answer if you have an exotic use case or hardware that exposes you to an annoying issue.

However, it leads to one of the beautiful advantages of open-source: you can actually dig into the code and fix the issue yourself, then submit the fix! If you lack those kinds of technical skills, you can learn them, or maybe cajole a technically savvy friend into doing it. Or you can sponsor a developer to fix it, paying them directly. You can write a polite blog post about the issue to draw attention it. You have options.

These are all options you don’t have in the closed-source world, where your only option is to live with the issue until it happens to come to the attention of an executive, manager, or other decision maker who experiences it, or when user feedback indicates that it’s not as exotic as originally believed. However this is totally random; you have no control over the process. Also, once this happens, engineers are pulled off other tasks and asked to fix the issue. So while it does eventually get fixed, no new engineers are ever hired specifically to fix little issues, so as a result the pace of development for everything else slows down a tiny bit.

The open-source world has a real advantage here, in my opinion. There are many more ways for users to get involved in fixing the problems that affect them.

So what a great time it is to fix some of the little annoying issues you’ve been living with forever! If you’re strapped for ideas, you can find some lists of bugs here. We make it really easy to compile KDE code from source, so you can get hacking. Check out https://community.kde.org/Get_Involved/development

So what are you waiting for? GET TO DA CODE!

DO IT NOW!!!!!!

Help me choose a new laptop

I’ve been doing all my development work on a late 2016 HP Spectre x360 for the past few years. Though a fantastic machine overall, it’s starting to fall apart: the screen backlight has partially burned out, the battery barely holds a charge anymore, and the trackpad sends a double or triple click when I press down on it. This thing has been worked hard and dragged all over the country and the world, so it feels like the time is coming for a replacement.

So I did what a typical OCD nerd does for a major purchase: I made a spreadsheet with all reasonable options and gave myself terrible analysis paralysis! 🙂

Analysis paralysis in action

For my research, I found two resources in particular to be invaluable: notebookcheck.com for its exhaustive long-form technical reviews, and Lisa Gade’s MobileTechReview YouTube channel for focusing on each machine’s overall user experience.

After nearly a month, I made my decision: the late 2019 Dell XPS 13 with a 6-core CPU which I figured would really speed up my code compile times, and the rest of the laptop seemed super high quality. Unfortunately, after it arrived I found that I did not like the feel of the keyboard: the key activation force was quite mushy, and the travel was low. But even worse, the display suffered from unbelievably terrible ghosting–which I had been warned about in reviews, but foolishly ignored–and it emitted an awful coil whine when in use. I sent it back. What a nuisance!

So I moved on to the second laptop in my list: the early 2020 HP Envy 13. I ignored reviews complaining about the trackpad surface not having a glass coating, which again was stupid: I didn’t like the feel at all of the rough plastic texture. But the rest of the laptop was solid, and the trackpad surface wasn’t a fatal flaw as these tend to smooth out over time in my experience. I decided to keep it. Not having yet wiped the disk to install openSUSE Tumbleweed (my current OS of choice), I performed the initial set of Windows updates just in case there were any firmware updates. It completed and I rebooted… and then the laptop became a brick! It was stuck in a half-on-half-off state, with the power LED illuminated, but no activity. The laptop could neither be turned on, nor fully powered down. I returned that one too.

So now I’m kind of feeling stuck. Out of two well-researched laptops, I’ve gotten two lemons, and I’m feeling like it’s time to reach out to the wider KDE community for assistance.

I need your help to find a good laptop!

What I’d like

This will be my one and only computer, used for both work/KDE development and also my personal stuff, so like Mary Poppins, I need for it to be practically perfect in every way (that’s not too much to ask, is it!?):

First, it needs perfect or near-perfect Linux compatibility; there’s no point in buying great hardware if it doesn’t work with your software.

Next, the built-in input and output devices that I’m going to actually use the computer with must be perfect:

  • Perfect keyboard: durable; firm key activation force; at least 1.3mm of travel, preferably more; firm bottoming-out feel; not too noisy; black keycaps that are not too large, with white lettering and backlighting; dedicated Home, End, PageUp, and PageDown keys for faster text editing; ideally dedicated media play/pause, forwards, and backwards keys. The keyboard is very important as I’m typing all day.
  • Perfect screen: 400+ nits of brightness; good refresh rates/no visible ghosting; close to 100% sRGB coverage; good color reproduction; must have touch functionality (I need to be able to test for touch friendliness with my and other people’s patches); 16:10 or taller aspect ratio preferred; full HD resolution is preferred, but 4K is acceptable. Size-wise, I like 13.3″ – 14″ screen sizes, but would consider a 15-incher if the case isn’t so big that it impedes portability in a backpack (more on that later).
  • Perfect trackpad: smooth, ideally glass-covered surface; aspect ratio matches that of the screen; button is durable and will last a long time; uses Microsoft Precision drivers on Windows (sign of good-quality hardware).
  • Excellent speakers: Reasonably loud, forward/upward firing, preferably four, ideally with some woofers for at least a bit of base.

Next, it needs to be powerful. I want 16 GB of RAM with excellent multi-core CPU performance to improve my code compilation times. This means good thermal management too, so that that performance can be maintained and the machine doesn’t damage its battery or other internal components with excessive heat, which I suspect happened with my current machine.

Also, I need for it to not have an NVIDIA GPU. I have no graphical needs beyond what an integrated GPU can accomplish, and don’t want to deal with Plasma-on-NVIDIA drama. Sorry, NVIDIA.

The machine needs to have a solid and durable metal case, as I will be traveling domestically and internationally with it multiple times a year (once the world beats COVID-19, that is). For similar reasons, it should be reasonably lightweight and get very good practical battery life. Extreme thinness is not required, but excessive thickness would be nice to avoid, as I like to travel to Europe for work events and conferences with only a backpack and no checked or hand luggage. An excessively thick laptop takes up space needed for socks and underwear (unless I’m going to Germany, in which case I wash them in my hotel room and dry them on the towel warmer! TMI… sorry-not-sorry!).

Finally, I want the laptop to not look stupid. No bling-bling effects, no gaudy blue and gold two-tone color effects, no flashing multicolored lights, no fake (or real) wood, no trying to look like an expensive watch or a traffic accident, no sharp chiseled edges–none of that attention-getting crap! Just a basic boring matte silver or gray metal case. Ideally it will not be a fingerprint magnet.

Within reason, price is not a practical consideration as this is a business expense for me and I am comfortable spending big bucks on something that provides my livelihood which I expect to keep for several years.

So given these conditions, what do people recommend? Help me, KDE community, you’re my only hope!

This week in KDE: Plasma 5.19 beta and more

The KDE Plasma 5.19 beta has been released! We’re very proud of the work that’s gone into 5.19, but it is no doubt buggy and in need of QA. Please help us find all the bugs we missed! Go test it in your favorite distro; options include KDE Neon Testing or Unstable editions, openSUSE Krypton or KDE:Unstable repos, Arch’s kde-unstable repos, and probably many more I’m not familiar with (please tell me!).

But wait, there’s more…

New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

Go test that Plasma 5.19 beta! Read the first paragraph of this post to see how. 🙂

More generally, have a look at https://community.kde.org/Get_Involved to discover ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

Why the animations in your Plasma 5.18 feel slow now, and when it will be fixed

KDE Frameworks 5.70 was just released and should be trickling out to users of rolling release distros at any time. Various Arch users who have already received the update have been complaining about slow animations in Plasma, and I wanted to write a blog post to explain what’s going on here. It is a bit technical so let me start with the TL;DR version: “releasing software is complicated and this will be fixed once Plasma 5.19 comes out next month.”

—

For the longer version, allow me to explain:

This is caused by an unfortunate timing problem stemming from the different Plasma and Frameworks release schedules.

Plasma and Kirigami-based apps use standard duration values for animations (e.g. units.shortDuration, units.longDuration, etc.) to keep animation timings relatively consistent. These duration values are set in the respective Frameworks: plasma-framework and kirigami.

I recently discovered that Plasma units were far shorter than Kirigami units. For example a Kirigami units.longDuration unit is 250ms, while a Plasma units.longDuration unit was 120ms–over two times faster. A Kirigami units.shortDuration unit was 150ms, while a Plasma units.shortDuration unit was 24ms–almost too fast to see. In practice the Plasma units.shortDuration value was useless and always had to be multiplied by something. Even most of the longDuration values were being multiplied by random numbers too. So we wound with animated transitions throughout Plasma having timings like units.shortDuration * 4 or units.longDuration * 3. It was a classic problem of badly-chosen library constants that force apps to work around them and munge them this way and that, totally defeating defeated the purpose of using standardized values in the library in the first place. There was not actually any standardization at all!

I needed to fix this as a part of my introduction of a new animation-using component, the ExpandableListItem (which I keep meaning to blog about): https://phabricator.kde.org/D28033

I fixed the Plasma units to be the same as the Kirigami units in https://cgit.kde.org/plasma-framework.git/commit/?id=0739113a4477e1eb25bf13b0040af5a502d3ef0a, and then fixed Plasma itself to no longer multiply the units in a series of other commits. However this presented an issue: Plasma and Frameworks have different release schedules! So people will not get both aspects of the change at the same time! This means that for a time, some people would have animations that were undesirably slower or faster. How should this be handled?

Unfortunately there is no easy way to do conditionals depending on a frameworks version in QML code as we can in C++ code, so that easy option was not available. Probably something to look into implementing.

So we had a few options. One was to avoid solving the problem until Plasma 6, several years in the future, at which point we could do everything at once. This was not deemed satisfactory, as the issue was blocking the ExpandableListItem patch which was needed for a task targeted for Plasma 5.19. Another option was to leave the existing units alone for Plasma 5, and add new units with different names now, and have Plasma 5.19 use those new differently-named units. This would have avoided the issues you’re all experiencing, but would have resulted in terribly confusing code. In the end we decided to spare ourselves the potential for new bugs stemming from that.

The final option was to wait to make the Frameworks change in a Frameworks release that lines up as closely as possible with the Plasma 5.19 release. Plasma 5.19 depends on Frameworks 5.70, but always releases about a month later, at which point Frameworks 5.71 will be out. This option therefore presented two sub-options: put the units change in Frameworks 5.70 or 5.71?

If we did it in 5.70, there would be a one-month period in which people using rolling release distros suffer from slow animations, because they have Frameworks 5.70 but not Plasma 5.19 yet.

If we did it in 5.71, the period of time in which people suffered from this issue would still exist, but it would potentially be shorter. However depending on distro release schedules, if a distro released Plasma 5.19 *before* Frameworks 5.71, then animations would become too fast to see! Furthermore, any discrete release distro in the future that shipped Plasma 5.19 with the 5.70 Frameworks version it depends on rather than a newer one would then have all of its users suffer from the bug forever (or at least until its packagers backported the plasma-framework commit).

So shipping the units change in Frameworks 5.71 did not seem to be a realistic option. In the end I shipped the units change in Frameworks 5.70 knowing that rolling release distro users (myself included) would suffer from slow animations for one month. Sorry. 😦 It will all be fixed in Plasma 5.19.

Software is complicated!

This week in KDE: Get new clipped subsurface Dolphin folder sizes

This week a lot of work was put into improving the reliability of the “Get new [thing]” feature integrated into many KDE apps and System Settings pages. Also, several Wayland improvements landed, including subsurface clipping. Finally, a major Dolphin feature request was implemented, allowing the display of on-disk folder sizes! There are also scads of other things, so read the full list and be happy:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

We recently updated our documentation for how to build and run Plasma Mobile locally on your desktop machine: https://community.kde.org/Get_Involved/development#Plasma_Mobile. Plasma Mobile is really amazing and advancing at warp 9 speed, so please do check it out and see what all the fuss is about! More information can be found at https://www.plasma-mobile.org

More generally, have a look at https://community.kde.org/Get_Involved to discover ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.