This week in KDE: a mad bugfixing spree

Plasma 5.25’s first bugfix release came out a few days ago, and the next one is due early next week. Hopefully most of the bugs you folks found will have been fixed! And among those are few 15-minute bugs too.


Occasionally people ask, “Jeez, it feels like you guys are fixing bugs all the time… shouldn’t they all be fixed by now? Why is your software so buggy?” Thing is, that’s the nature of software. There are always more bugs to fix, no matter how long you work at it. And the more people who use it, the more bugs they’ll find. This is universal, for every piece of software. The best metric is not really “number of bugs fixed,” but rather “egregiousness of bugs fixed.” You want to see that the bugs we fix get weirder and more esoteric over time, which indicates that the basics are becoming more reliable. We’re not all the way there yet, but I believe we are making progress!

15-Minute Bugs Resolved

Current number of bugs: 59, down from 65. 0 added, 2 found to be upstream issues, and 4 resolved:

Session-restored windows no longer restore themselves to the wrong virtual desktops when using the now on-by-default Systemd boot feature (David Edmundson, Plasma 5.25.2)

In the Plasma X11 session, buttons in the Present Windows and Overview effects no longer only work every other time you click them (Marco Martin, Plasma 5.25.2)

Switching between Plasma widgets using the “Alternatives” panel now saves their settings, so if you switch back to an old widget you were using before, its settings are remembered (Fushan Wen, Plasma 5.26)

In the Plasma X11 session, the search icon displayed inside search fields throughout Plasma widgets and KWin effects is no longer comically large (me: Nate Graham, Frameworks 5.96)

Current list of bugs

New Features

In the Plasma Wayland session, it’s now possible to disable middle-click paste (Méven Car, Plasma 5.26):

User Interface Improvements

Tooltip visibility for pages in System Settings now respect the global setting to disable tooltips (Anthony Hung, Plasma 5.24.9)

The Edit Mode toolbar now splits itself into multiple rows when the screen isn’t wide enough to accommodate it (Fushan Wen, Plasma 5.25.2)

Discover now determines the priority of your Flatpak repos (when you have more than one configured) from the command-line flatpak tool, and changes the priority there too if you change it in Discover, so the two always remain in sync (Aleix Pol Gonzalez, Plasma 5.25.2)

The Pager, Minimize All and Show Desktop widgets now handle Panel keyboard focus properly (Ivan Tkachenko, Plasma 5.26)

Entering or exiting the letter grid in Kickoff now plays a nice little animation (Tanbir Jishan, Plasma 5.26):

When the wallpaper changes from one to another, it no longer becomes slightly darker during the animated transition (Fushan Wen, Plasma 5.26)

The clipboard widget now uses a more appropriate and less visually busy character to represent tabs (Felipe Kinoshita, Plasma 5.26)

Kirigami-based apps with sidebars in desktop mode no longer secretly show an invisible close button in the sidebar’s bottom-right corner that you can accidentally click on to confusingly close the sidebar with no way to get it back (Frameworks 5.96)

When app icons change on disk, Plasma now notices this and displays the new icon within 1 seconds, down from 10 seconds (David Redondo, Frameworks 5.96)

The “Battery and Brightness” widget now shows you the battery level for connected wireless touchpads (Vlad Zahorodnii, Frameworks 5.96)

The “Open With…” dialog that you’ll see in non-sandboxed apps now has a “Get more Apps in Discover…” button, just like the different-looking dialog seen in sandboxed apps (Jakob Rech, Frameworks 5.96):

And yes, before you ask, it’s silly that we have two different “Open With…”dialogs with different appearances and codebases. Unifying them is an active area of work!

Bugfixes & Performance Improvements

Elisa’s playback slider once again works properly when the current track is longer than about 3 minutes long (Bart De Vries, Elisa 22.04.3)

The remote desktop dialog for sandboxed apps now appears when expected (Jonas Eymann, Plasma 5.24.6)

When run from a Flatpak, the Pitivi app no longer crashes on launch when using the Breeze cursor theme (Mazhar Hussain, Plasma 5.24.6)

In the Present Windows effect, it’s once again possible to activate windows that are on a different screen from the one used to type text into the filter (Marco Martin, Plasma 5.25.2)

External USB-C displays once again work properly (Xaver Hugl, Plasma 5.25.1)

Fixed a very wide variety of keyboard searching, focus, and navigation issues with the new Present Windows effect, bringing it back up to its keyboard usability in Plasma 5.24 (Niklas Stephanblom, Plasma 5.25.2)

It’s once again possible to select desktops with the keyboard in the Desktop Grid effect (Vlad Zahorodnii, Plasma 5.25.1)

In the Plasma X11 session, tiling windows to the left or right no longer sometimes cause an odd flicker (Vlad Zahorodnii, Plasma 5.25.1)

The screen locker no longer crashes if you’ve manually installed support for the Howdy facial recognition system (David Edmundson, Plasma 5.25.2)

Square highlights once again appear on hover in the Application Dashboard (Ivan Tkachenko, Plasma 5.25.2)

Using the new “Tint all colors with accent color” now tints the titlebar too, without you having to also check the checkbox that explicitly applies accent colors to the titlebar (Eugene Popov, Plasma 5.25.2)

Setting advanced firewall rules once again works (Daniel Vrátil, Plasma 5.25.2)

When using a traditional Task Manager, open tasks no longer spontaneously re-arrange themselves when a pinned app is moved with the “Keep launchers separate” option unchecked (Fushan Wen, Plasma 5.26

Inline buttons in NeoChat’s Accounts list are once again visible (Jan Blackquill, Frameworks 5.96)

Overlay sheets no longer sometimes have excessive bottom margins in desktop mode (Ismael Asensio, Frameworks 5.96)

…And everything else

This blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, check out our 15-Minute Bug Initiative. Working on these issues makes a big difference quickly!

Otherwise, have a look at https://community.kde.org/Get_Involved to discover ways to 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.

22 thoughts on “This week in KDE: a mad bugfixing spree

  1. What I wish for is to fix the crash related bugs to improve stability, 5.23 was really much better and stable than 5.24 and 5.25, some really simple operations in Klipper widget and Spectacle can crash the whole desktop, and some fixes are pushed only to Qt6 which will take really long time (maybe be years) to have them because 5.25 is still based on Qt5.15

    Like

    1. Also wanted to ask about this. Actually, this is the only reason I didn’t switch to Plasma.

      Like

  2. “Occasionally people ask, “Jeez, it feels like you guys are fixing bugs all the time… shouldn’t they all be fixed by now? Why is your software so buggy?” Thing is, that’s the nature of software. There are always more bugs to fix, no matter how long you work at it.”

    That’s true, but wouldn’t you say that the expansive nature of KDE (trying to give as many options as possible everywhere) contributes to the number of bugs? Don’t get me wrong, that’s what I love about KDE, but isn’t that a factor?

    Great work this week as always, thank you for all you’ve done for this software and its community ^^

    Like

    1. It’s a factor, but to make a long story short, it’s the only option we have. If we reduce our scope to match our resources, we become a pale shadow of GNOME. We have to double down on our strengths by increasing our resources to match our scope.

      Liked by 1 person

    2. I don’t think KDE has to worry about being a pale shadow of GNOME. There are other DEs (LXQt, XFCE, etc) whose scope matches their resources, that still excel compared to GNOME. Keeping their scope under control also leads to improved stability.
      In conclusion, it’s worth stopping the ever-increasing scope creep of KDE, as Peterson Silva suggests this is starting to show real problems.

      Liked by 1 person

    3. I think your choice of examples kind of supports my point: those other DEs *are* pale shadows of GNOME, with small fractions of its userbase and developers. In addition most of them rely on GNOME technologies under the hood, which means their fortunes are inextricably tied to GNOME and they cannot ever exceed it. KDE’s scope is huge because its tech stack is deep enough to make it a real alternative to everything GNOME, not just the UI layer on top.

      Liked by 1 person

    4. Maybe XFCE uses GNOME tech (GTK) but surely not LXQt? In any case, they’re definitely not GNOME and I don’t see how they are just pale shadows of GNOME. By that logic, since KDE is tied to Qt technologies, doesn’t that mean your fortunes are inextricably tied to Qt and cannot ever exceed it? Case in point: https://bugs.kde.org/show_bug.cgi?id=394698

      My point is, KDE is extremely flexible as is, and there’s nothing to worry about if KDE takes a break from the constant expansion of its scope. Maybe even cutting some fat. Is KDE trying to be a usable, stable desktop environment, or just focusing on being the “anti-GNOME” by cramming lots of features at the expense of leaving long-standing issues unfixed and creating more issues in the process?

      Liked by 2 people

  3. “In the Plasma Wayland session, it’s now possible to disable middle-click paste”

    This is great!

    One thing I miss coming from Windows is the ability to press the middle mouse button and then scroll by moving the mouse up or down (autoscroll). Luckily Firefox has it built in as an option, but everywhere else I just have to scroll and scroll and scroll. I hope that one day it will be possible to use autoscroll everywhere on Linux, but I’m not sure if that would even be possible (I have no idea how it is possible that it works “globally” under Windows). Maybe this change will bring us closer to one day having this feature available.

    Like

    1. I am not a fan of this feature, I always switch it off when I have to work on Windows.
      But I think this is more than possible in Linux. You just need to catch that wheel globally (for example with evsieve), then launch a handling utility that will translate relative movements to wheel events, and kill the handler after another press of wheel.
      I would recommend to at least ask a question about this in unix.stackexchange.com site instead of commenting in blog, because this way it will not be lost.

      Like

  4. Impressive how quickly you have fixed the first bugs of version 5.25.

    I was worried about not being able to move individual windows in the desktop grid, I thought we would be like this for a while.

    Congratulations and thank you very much developers!

    Liked by 1 person

  5. Some thoughts on why bugs are still appearing. I don’t call to any action or blame anyone, but:
    1) KDE provides software which is in development perpetually. You don’t stop adding features. You never really finish. And when you finish, you replace that finished component with new, which is buggy again: for example, perfectly working KSysGuard was replaced by currently buggy System Monitor. Well-scoped software with clearly defined tasks and specification can be made bug-free.

    2) Practice show that large-scale open source projects are bad at QA/QC. Code base is large, and there is a lot of space for bugs to show up; and you can’t make people stop working on features and debug the code. 15-minute bugs initiative doesn’t enjoy much enthusiasm to my mind: writing new code is much more exciting than fixing bugs.
    Only small open source projects, which are written by a handful of people with coherent vision are efficient at quality control. Look at s6, for example

    Like

    1. The only way you can freeze a piece of software and call it “done” is if you control its inputs, outputs, and the hardware and platform it runs on. Then it’s feasible. But the moment any of those things change, you have to un-freeze it to handle the change, or else bugs creep in. With GUI software for users, you control none of those things; the world around the software is itself constantly changing, as are user expectations about your software. So even if you only freeze feature and UI development and say “we’ll only fix bugs from now on”, then eventually the software itself becomes obsolete because it doesn’t have the features, the UX, or the appearance of other competing offerings in the same space. This just doesn’t work.

      Unfortunately you’re right that it’s hard to motivate volunteers to perform QA and fix un-glamorous bugs. This is one of the reasons why I’ve proposed hiring professional QA and bugfixing engineers. See https://phabricator.kde.org/T15627

      Like

    2. You are right that one cannot call software ‘done’. And this is totally fine to review scope of software. Maybe my words are more applicable to the world of system software, while KDE provides both system and applied software.

      Looking forward to see what will happen with your initiative!

      I maybe will join QA efforts once I learn Qt

      Liked by 1 person

    3. Indeed, there’s a big difference between writing software for a largely closed system and writing software were the inputs and the environment around it are constantly changing. Unsurprisingly, this turns out to be really hard!

      Like

  6. Criticizing the developers for bugs is so unfair. It misses the critical point that these people are almost always volunteers working on their free time and -as far as I know- not getting paid. As users. I think we should be grateful to the developers and contributors of KDE who are doing an amazing job, producing some of the best pieces of free and open-source software. And bugs which really do get in the way are both rare and patched very quickly, which is really impressive and encouraging.
    What you mentioned about KDE hiring engineers to fix bugs sounds like a very exciting suggestion. I wonder why this hasn’t been done already and whether financial income of KDE plays a part in that or not. But since bugs deter inexperienced and non-tech-savvy users to a much greater extent, having employees to do the time consuming job of fixing bugs will make Plasma and other KDE software a lot more accessible to home users. If one of the goals of KDE is to provide people with free software -with all the positive characteristics of FOSS in general – this seems a to me as a big step towards that goal.

    Like

Leave a comment