The last few weeks in KDE: It’s coming… it’s coming… it’s coming

Wow, it feels like it’s been a while! And while many of KDE’s contributors have been enjoying some holiday and vacation time, quite a lot happened too! We’re getting pretty close to the projected February 28th release day for the KDE 6 megarelease, so all hands have been on the bug-fixing deck.

Overall we’re in good shape. Despite the large number of open bug reports, most are not serious, and I have confidence that we’ll get the remaining major ones done before the final release. Of course, the best way to make sure that happens is to help out!

KDE 6 Mega-Release

(Includes all software to be released on the February 28th mega-release: Plasma 6, Frameworks 6, and apps from Gear 24.02)

General infoOpen issues: 238

UI improvements

It’s now possible to quickly apply a wallpaper to all screens at once (Prajna Sariputra, link)

You can now set a custom mouse pointer speed, just like you can for the touchpad (Denis Zhdanov, link)

Discover Notifier no longer appears in your System Tray (even just the inactive area) unless it actually has something to notify you about–which means you can remove it permanently by simply telling Discover to never check for updates automatically on System Settings’ Updates page (Yifan Zhu, link)

Breeze-themed buttons and text field now always have the same height so they’ll never look slightly different when adjacent to one another (Akseli Lahtinen, link)

Throughout KDE software, the way symbolic icons (i.e. those whose names end with -symbolic) are found has been improved: when a symbolic icon is not found and the system has to fall back to a more generic icon, you’ll now get a symbolic version of that icon if it exists (Joshua Goins, link)

You can now configure Plasma to turn off the screen at the same moment when it locks (Jakob Petsovits, link 1 and link 2)

Bug fixes

Important note: I don’t mention fixes for bugs that were never released to users; it’s just too much for me (it would probably be too much for you to read as well), and most people never encountered them in the first place. Because we’re in the middle of a big Plasma dev cycle, there are a lot of these bugs! So big thanks to everyone who’s made it a priority to fix them!

Ark now preserves extended attributes of files in archives when editing and saving their contents (Kristen McWilliam, link)

Fixed a file descriptor leak in Plasma that could cause it to run out of file descriptors and crash under certain circumstances (Moody Liu, link)

Fixed an issue that could prevent the GlobalProtect SAML authentication method in OpenConnect VPNs from working (Rahul Rameshbabu, link)

Night color can now co-exist with color correction using ICC profiles–at least in the Wayland session (Xaver Hugl, link)

When using the weather widget’s DWD weather provider, you’ll no longer sometimes see nonsensically high temperature values shown in the forecast (Ismael Asensio, link)

Tabs in the weather widget no longer sometimes overlap in certain circumstances (Ismael Asensio, link)

Plasma’s “Alternatives” popup now follows the opacity level of its parent panel (Niccolò Venerandi, link)

When showing a preview of the selected Task Switcher style, clicking away from the preview now closes it as expected in the Plasma Wayland session (Ismael Asensio, link)

Other bug information of note:

Performance & Technical

The colord-kde repo has been ported to Qt6, so that color management on X11 works too (Nicolas Fella, link)

Reduced the background CPU usage when moving the pointer (Xaver Hugl, link)

A wide variety of pieces of transient state in QtWidgets-based apps are now stored in the state config file, not the settings file used for persistent user-set settings. This is a part of a very vocal crowd’s favorite bug! (Alexander Lohnau, link)

Automation & Systematization

Added GUI tests to make sure several Plasma bugs don’t recur (Fushan Wen, link 1, link 2, link 3, and link 4)

Added an autotest to make sure symbolic icon fallback works properly (Joshua Goins, link)

…And Everything Else

This blog only covers the tip of the iceberg! 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

Thanks to you, our Plasma 6 fundraiser has been a crazy success! I originally thought the goal of 500 new KDE e.V. supporting members was over-optimistic, but you’ve all proven me happily wrong. We’re now up to an incredible 627 members and unlocked multiple stretch goals! The first one has been met, but the second one is still on offer. So if you like the work we’re doing, spreading the wealth via this fundraiser is a great way to share the love. 🙂

If you’re a developer, work on Qt6/KF6/Plasma 6 issues! Which issues? These issues. Plasma 6 is very usable for daily driving now, but still in need of bug-fixing and polishing to get it into a releasable state by February.

Otherwise, visit https://community.kde.org/Get_Involved to discover other 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!

25 thoughts on “The last few weeks in KDE: It’s coming… it’s coming… it’s coming

  1. The discover notifier will still notify about pending reboots if you made updates through discover. To really permanently hide it (even for reboot notifications) you still have to run `DiscoverNotifier –hide true`.

    Like

    1. You can also go in the notification settings and on list of items select „Never” for Discover. It will then be accessible when in the extended tray dash, but it will never appear on the panel directly

      Like

  2. Hello Nate,
    Plasma 6 is doing greate progress on improvisations.

    I tried Beta 2 and felt there are still some small things that can be addressed or at least discussed.

    I do have list/bunch of suggestions on various categories like panel, desktop, dolphin, etc. I am not saying these all needs to be addressed, what I need is someone should just take a look what is suggested, accepting/rejecting it is something that would come later, which is fine.

    I don’t know how shall I submit all suggestions across various modules.

    Btw, i do have account on KDE bugzilla portal and have 2 recent tickets: 479035 (open, its about critical clipboard behaviour) and 479036 (closed by kde with no explanation, its about expected default for touch pad).

    Like

  3. I do not fully understand what this bug fix does:

    ‘Throughout KDE software, the way symbolic icons (i.e. those whose names end with -symbolic) are found has been improved: when a symbolic icon is not found and the system has to fall back to a more generic icon, you’ll now get a symbolic version of that icon if it exists (Joshua Goins, link).’

    Does this mean that the system continues to look for a -symbolic version of that icon in other theme folders? For instance, that if an icon theme called ‘MyTheme’ does not have such an icon it will load an icon from any other theme instead, as long as it has the -symbolic suffix?

    If so, that does not sound like a fix to me at all – since the system will now apply that other theme’s design instead of respecting the original theme’s design choices.

    Like

    1. No, what it does is to keep looking for more generic symbolic icons within the same icon set, instead of falling back to non-symbolic icons.

      Quick and dirty explanation (my mental model 😅): Icons are named as a-b-c (with each level giving you a more specific icon), and symbolic icons always end with -symbolic.

      With the current (“old”) code, if the system couldn’t find “a-b-c-symbolic”, it would simply strip “-symbolic” and then search for “a-b-c” and never search for symbolic icons again.

      With the new code, the system will search for “a-b-symbolic” and so on.

      A more concrete example from the merge request ( https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/118/diffs?commit_id=2d22b9d8798f1ba2642aa3b982a65c9865fbf52d ):

      For a non-existing “media-optical-dvd-video-symbolic”, the old code would fall back to “media-optical-dvd-video” and so on; the new code falls back to “media-optical-dvd-symbolic” and so on, always keeping the “-symbolic”.

      Like

  4. On one side I can’t wait for the new release, on the other side, I expect it to be buggy, despite all the work. Plasma is too big, too complex, and it’s fine if the release has its shares of problems. When released to the masses, the sheer exposure, will ensure that a lot of new bug reports will appear.
    Because I am currently using my personal laptop for work as well, I cannot rush and install a fresh release as I was doing some time ago. I’m staying on Manjaro stable branch now, which means many weeks of delay. The wait will be painful… Unless, I make the jump to check it out and in case of serious issue, I restore the backup? Hmm… 😉

    Like

  5. A silly question maybe, but… is there a live-usb ISO image that I can try to test it, e.g. to see if my workflow wasn’t broken (I’m currently using an i3 + KDE; I know tiling capability have been merged to kwin but I haven’t gotten to testing/configuring it yet) ?

    A month ago I tried KDE Neon unstable which I thought was purposed for that exactly, but it doesn’t even start graphics interface upon booting; and as I found on reddit, apparently it rarely works for anyone.

    Like

    1. I’d like to point out there’s an old r/kde thread called `How to test Plasma 6 ?` that still has no answer that doesn’t require you to mess around with your working system (besides Neon-unstable which doesn’t work). That is to say, there might be many people who would really like to test KDE6 before it gets released but are afraid of breaking their current systems and instead would need an ISO build or something that can be booted without having to install it anywhere.

      Like

    2. In fact there are several options that don’t mess with your working system. Building from source doesn’t mess with it since the built software lives in your home folder and does not interfere with system packages at all. And any of those distros can be tested in a VM–including Neon Unstable; I was just doing this yesterday.

      Like

  6. I have no spare computer for testing. Besides, I want to use the platform of my choosing, so I’m far more interested to report bugs after the release on Arch/Manjaro side, when the update is on bare metal.

    Like

  7. KDE is so mature and feature full desktop environment. It’s a joy to set up for your liking and to use as a daily driver. Keep up the good work and i am looking forward to Qt 6 port.

    Liked by 1 person

  8. “You can now configure Plasma to turn off the screen at the same moment when it locks”

    I don’t know how much money it will save me on my electricity bill, but I’ve now sent at least part of it in advance to a fundraiser for KDE. Thanks for the good work.

    Liked by 1 person

  9. I’m writing to you, because you are interested in Wayland and what are its showstoppers or limitations.

    I’m again coming with this issue of Firefox not raising to the foreground after clicking a link in an external app.

    I checked:
    – various DEs
    – various OS installs on various computers
    – various virtualbox live and installed OSes
    – various browsers set on XWayland or Wayland

    and with 100% accuracy (always replicable), the problem exists on Wayland window only, regardless of DE or even a browser. This is not a Firefox issue. When Chrome and Chromium were opened as native Wayland windows with those flags:

    $ google-chrome-stable –enable-features=UseOzonePlatform –ozone-platform=wayland
    or
    $ chromium –enable-features=UseOzonePlatform –ozone-platform=wayland

    they behaved exactly as Firefox, meaning that the links clicked on apps like Thunderbird or Libre Office Writer were not raising windows to the top (when the browser was already opened and not on top). When a link was clicked before a browser was opened, then a browser window was opened on top without problems. Wayland seems to be well capable of doing it (putting window on top after clicking a link), but from some weird reason, it is set in a way that it differs from X11 or Windows experience. This is a behavioral regression. There is no good reason for it. X11 and Windows have decades of experience and there is a reason why on them clicking a link makes the browser go to the top layer.

    There were people claiming that it works for them, but I doubt they were really checking if the browser is opened in Wayland mode. For that, it’s best to use:

    dbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

    Again, to replicate it:
    1. Open a browser (any browser) as native Wayland window.
    2. Check with Kwin debug console if it’s really a Wayland one.
    3. Open Thunderbird or Libre Office Writer with links, click on them.

    Again, a browser must be already opened and in Wayland mode.

    Now, my question to you Nate is, where we should report such Wayland issues?

    Like

    1. It’s definitely not 100% broken since it works for me in all the apps I use regularly–including opening links from Thunderbird in Firefox.

      The way window activation works on Wayland is that both the sending and receiving app need to implement the xdg_activation protocol (and the compositor has to as well, but KWin does). If one of them doesn’t implement it, or implements is incorrectly, then the window won’t get raised as expected.

      Unfortunately it’s challenging to debug who exactly is at fault here when it doesn’t work. It would be a good question for the #kwin matrix room.

      Like

  10. Awesome work :),
    I see one big flaw with the whole solution atm and that is unavailability to escalate the privileges for modification of files owned by root (getting some popup prompting for password etc.) the kio-admin is really clunky.
    Also, there are few bugs;
    * the plasma shell is crashing every here and there (for instance when I connect to VPN using the plasma network manager)
    * the wayland windows sometimes loses input control (both mouse and keyboard) and even though they remain on the top they can be “clicked through” and the input is actually still attached to another application and it can only get fixed by displaying clicking on “minimize all windows (show desktop) widget” or by sending the window to different desktop and back.

    Like

Leave a comment