As has been reported in various other places already, this week the “master” branch of Plasma-aligned software repos have been ported to Qt 6. Work is ongoing, but the actual change-over is happening very quickly, and adventurous people are able to run Plasma 6 in a usable state already! This builds on years of work to port old code away from deprecated APIs and libraries that was just quietly happening in the background all along, pushed along by people like Nicolas Fella, Friedrich Kossebau, Volker Krause, and many others. It can be fairly thankless and boring-looking work, but it’s incredibly important, and the foundation of how quickly this technical transition has been able to happen. So I find myself feeling quite optimistic about our chances of shipping a solid and high quality Plasma 6 this year!
…And that’s the reason for this being a somewhat light week in terms of other things. But fear not! Plasma 5.27 continues to be maintained and bugfixed!
There’s now an option to change the visual intensity of the outline drawn around Breeze-decorated windows, or to disable them entirely. Currently this is slated to be released in Plasma 6.0, but we’re considering backporting it to 5.27 as well. Stay tuned! (Akseli Lahtinen, Plasma 6.0. Link):
User Interface Improvements
The new portal-based “Open With” dialog is no longer used by non-portal-using apps; they now get the older dialog again. This is still the future design direction we want to go in, but we plan to roll the new dialog out again only once it has all the features of the old dialog, so that nothing is lost in the transition (me: Nate Graham, Plasma 5.27.3. Link)
Linked buttons in Breeze-themed GTK apps like Rhythmbox now look better (Ivan Tkachenko, Plasma 5.27.3. Link):
Notifications in the history pop-up are now sorted chronologically, rather than by a somewhat difficult to understand combination of type and urgency (Joshua Goins, Plasma 6.0. Link)
The way sizes and positions of KDE app windows are remembered for multi-screen setups is now fundamentally more robust, so you should see fewer circumstances of windows having the wrong size and position when using multiple screens, especially when the specific screens change (me: Nate Graham, Frameworks 5.104. Link)
It’s now possibly to directly delete items that are already in the trash (Méven Car, Frameworks 5.104. Link)
(This is a curated list of e.g. HI and VHI priority bugs, Wayland showstoppers, major regressions, etc.)
When using an NVIDIA graphics card, after you reboot or wake the system from sleep, external screens are no longer usually inappropriately disabled, and also icons and text throughout Plasma are no longer sometimes missing (Ivan Tkachenko, Plasma 5.27.2. Link 1 and link 2)
Fixed a case where KWin could crash when switching window decoration themes (Vlad Zahorodnii, Plasma 5.27.2. Link)
In the Plasma Wayland session, when the clipboard history has been set to only one item, it’s now possible to copy text with a single copy action, not two (David Redondo, Plasma 5.27.3. Link)
Desktop icons on the active activity should no longer inappropriately re-arrange themselves when the set of connected screens changes. However during the process of investigation, we discovered that the code for storing desktop file position is inherently problematic and in need of a fundamental rewrite just like we did for multi-screen arrangement in Plasma 5.27. This will be done for Plasma 6.0, and hopefully make Plasma’s long history of being bad about remembering desktop icon positions just that–history (Marco Martin, Plasma 5.27.3. Link)
Gwenview now only registers its MPRIS interface when it’s doing something (i.e. playing a slideshow) that’s controllable over MPRIS, which should prevent it from sometimes hijacking your global media playback shortcuts while it’s running normally (Joshua Goins, Gwenview 23.04. Link)
Other bug-related information of interest:
- 14 Very high priority Plasma bugs (down from 16 last week). Current list of bugs
- 50 15-minute Plasma bugs (up from 44 last week). Current list of bugs
- 115 KDE bugs of all kinds fixed this week. Full list of bugs
Automation & Systematization
We now have a new tutorial on how to create cursor themes (Magno Lomardo, Link)
We now have a tutorial on uploading your KDE app to the Microsoft Store (Thiago Sueto, Link)
Added an autotest to make sure that “preferred” apps that are not actually installed are omitted from the Task Manager as expected (Fushan Wen, Link)
Added an autotest to ensure that we’re handling System Tray icons form apps correctly (Fushan Wen, Link)
Plasma now has a “codemap” file to help people learn what and where things are (Bharadwaj Raju, 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
If you’re a user, upgrade to Plasma 5.27! If your distro doesn’t offer it and won’t anytime soon, consider switching to a different one that ships software closer to its developer’s schedules.
If you’re a developer, consider working on known Plasma 5.27 regressions! You might also want to check out our 15-Minute Bug Initiative. Working on these issues makes a big difference quickly!
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!
And finally, KDE can’t work without financial support, so consider making a donation today! This stuff ain’t cheap and KDE e.V. has ambitious hiring goals. We can’t meet them without your generous donations!
34 thoughts on “This week in KDE: Plasma 6 begins”
Big thanks to Nicolas Fella, Friedrich Kossebau, Volker Krause, and the many others! 5.27 feels great and I am looking forward to Plasma 6!
LikeLiked by 2 people
Great news for early adopters and tinkerers, thank you all who is working on Plasma 6!
Out of curiosity, I tried to build the 6th version and unfortunately neither of 3 attempts I made were successful. There’s always something that breaks during compilation. I started to think if I revised my kdesrc-buildrc conf file correctly or not? I changed it to have `branch-group kf6-qt6`, `include /home/user/kde/src/kdesrc-build/kf6-common-options-build-include`, `include /home/user/kde/src/kdesrc-build/kf6-qt6-build-include`. Maybe I am missing something?
After numerous fails I came to realise that I don’t need it anyway, since the 6th version will probably not have configurable touchpad gestures, which makes it useless for me despite better Wayland support.
Don’t even had time to enjoy the last release and I already can’t wait to use the new KDE Plasma 6… Absolutely amazing work from all the developers. I am an average user (like millions of Mac and MS) and kinda of new on linux systems and I can say KDE system is fast, stable, super-customizable and cool! Far superior than the other counterparts (on linux as well). Whether you are a “terminal guy” or not.
LikeLiked by 1 person
looking good but all the drop-down menus in the first screenshot should be sliders instead.
LikeLiked by 1 person
There is no need for a submenu (this/that/both) in “set wallpaper.” The user should set their preference in settings once and not have to touch it ever again. You guys should work on simplifying the UI, not making it even more complex.
I do not agree.
How about an option to change the behavior of the scrollbar?
Regarding the code for rearanging icons, I would love if it would solve these two bugs:
(note that the first one was incorrectly closed, I think). That would make it robust when changing resolutions.
So aparently it wsa close correctly, so implementing this for icons should be much easier (I imagine the code would be pretty similar, possibly even simpler for icons).
> There’s now an option to change the visual intensity of the outline drawn around Breeze-decorated windows, or to disable them entirely.
r/kde is on fire!
The problem is KDE tries to keep everybody happy which means a GUI option for everything, and you just end up with overstuffed menus and preference panels.
Why not go down the OS-X route and just stick with a really good default. The window outline/shadows on OS X are playing a very similar trick, but the intensity and size looks perfect. No need to tweak!
Leave the tweaking to users who are happy to play around with editing config files, rather than overburdening the GUI.
That sounds terrible, in my opinion. If you want a DE that sticks with defaults and doesn’t really want the user editing it, go to GNOME. If you want to mess around with config files, go to a WM.
But why would 50 different KDE users really all want different outline intensity? The previous white highlighting line wasn’t adjustable in intensity.
I’ve never seen on a Mac forum, users complaining about the outline being too intense, or not intense enough. Its technically possible to create a setting that is ‘just right’ for 99% of humans. You just need trained graphic designers working on your team.
I mean, by your logic, KDE should allow 5 different options for the titlebar height, because some users might find the default too thin, and others find it too thick. Except they dont, because there is a sensible default.
A default setting requires user-configurability. We already aspire to have good defaults for our settings that are user-configurable. But adding user-configurability without a GUI to control it is a bad idea; this causes the code for those options to bit-rot as they’re not being exercised regularly. They can cause other bugs in the process, and make the code more complex. As a general rule for sane software engineering, if you’re going to add a setting in a GUI app, it needs a GUI somewhere for people to control it.
On OS X, the outlines are dark for the dark theme, which looks better and it’s what we’ll end up doing too. But this requires a bunch of technical work to get right, which is why it hasn’t happened yet. Ultimately the goal is to allow *all* separator colors to be controlled by a single user-customizable color in the color scheme, and to make that color be very dark by default for Breeze Dark, rather than the current color which is light.
Unfortunately KDE e.V. does not have the resources to hire even one professional full-time graphic designer, compared to Apple which is the most valuable company in the world, possessing the resources to hire thousands. If you’d like to see this change, please donate to the KDE e.V.! https://kde.org/fundraisers/yearend2022/ We would love to hire a designer if we had the funds.
Another difference is that users of Apple products want their systems to “just work,” and as such, they accept what Apple gives them unless it’s egregiously bad (and even sometimes then). Whereas Plasma’s userbase is over-represented by people with strong opinions on how they want their system to look and work and possess the great desire to change it from time to time. We want Plasma to be usable for people who want a “it just works” system, but with enough customizability to satisfy the fussy experts.
But adding this plethora of options makes it more difficult for non-nerds who go to system settings to change something more important, and get lost. You have to make a decision somewhere as to what point you stop adding more options or it hurts usability.
You could always go down the route you see in some Adobe software where, right at the bottom, there’s an advanced entry in the preferences list hiding a list of obscure things? Or maybe VLC’s way of simple/advanced preferences?
This outline intensity setting we added is buried waaaay down. It’s not going to confuse anyone.
The “basic/advanced settings” paradigm is risky. See https://community.kde.org/Get_Involved/Design/Lessons_Learned#Basic/advanced_modes
And this idea of Plasma’s settings being overwhelming is something I’m starting to think is mostly a harmful meme. We just got over a million new Steam Deck users and by far the most common comment I read about System Settings on the r/steamdeck subreddit is how sane, logical, and well-organized it is.
That’s not to say we can’t further improve the organization and drop settings that are too niche, overlap with other settings, or don’t work. And we are planning to do just that in Plasma 6.
Ultimately what we want to introduce into the memetic soup is the idea that you don’t *have to* customize Plasma to be happy and productive. You can if you want, but it’s designed to be sane and usable out of the box and you shouldn’t feel the need to make your system look like the Star Trek LCARS user interface and behave like i3. If you want to, go ahead. But this should be fun, not a chore.
I really appreciate that KDE is one of the few environments that allow me to truly “make it mine” these days. The theming and especially the colorization options are truly appreciated.
I also think that even without a full-time graphic designer, the default Breeze theme and overall layout works very well. My only two major gripes are the fact that so many windows open and the tabs/droplists/text fields are beyond the size of the window and I have to manually re-size it (something that I think the user should never have to do unless they are simply running an ancient low resolution) and I find the small monochrome ‘outline’ icons very jarring compared to the very pleasing full-size color Breeze icons.
If you don’t like all the options – leave it untouched. Do it like Mac Users and be happy with standard.
I like the Simple by default and owerful when needed approach in KDE. Where else do developers care so much what users want?
you ignored my point. if it’s logical to have a GUI menu with 5 different settings for window outline intensity, then why isn’t there already one for titlebar height? or intensity of highlight colour? etc.
or why not make the system settings for window decorations have 10 tabs, each with 12 options, so you can “powerfully” customise a subset of your operating system appearance?
i don’t know about you but i’m not staring at my window borders all day. i’m doing work.
> i don’t know about you but i’m not staring at my window borders all day. i’m doing work.
I only stare at my window borders if I need to do something there, else I don’t stare at them.
KDE adds customization for features enough users actually want. KDE doesn’t just add them in clunky fashion like Gnome does with its Tweaks app. KDE puts settings in logical places, and sets good defaults for them.
Far better than Gnome where you have barely any choice at all. Extensions? Good luck when they break with the next major release.
LikeLiked by 1 person
Hello Nate, i am currently using plasma 5.27.2 on arch and so far so good. I like the screen configuration applet, but i miss a visual indicator of what setting i am using. Obviously you can tell by looking to you screen, but a visual confirmation on the applet icon (like a tick or a box) could be good.
Have a nice day
Makes a bit of sense to me. Please submit a feature request for this at https://bugs.kde.org/enter_bug.cgi?product=KScreen&component=Plasma Applet.
I think the KDE team should wait like a year or before release “6.0 stable”. Get it ready before Kubuntu 24.04 LTS hits but not before. Plasma 6 MUST be as bug-free as possible. Get rid of all those 15-minute and high intensity bugs, get rid of the Wayland showstoppers, get rid of as many papercuts as possible.
KDE 4.0 was so buggy at release that it ruined KDE’s reputation for over a decade and let GNOME become the more dominant desktop despite GNOME 3 being an absolute shitshow. Don’t repeat that mistake please.
LikeLiked by 1 person
I don’t think we’re going to be able to get rid of *all* of the bugs. 🙂 But we are indeed planning to polish it up as much as possible before we release it! Definitely there’s been some learning from that mistake of the past.
100% of KDE effort needs to be put on bugs. The system right now is downright unusable.
Bugs completely prevent me from using: Kdenlive, Discover, and Neochat. Dr Konqui even fails on the attempt to submit the bugs from the programs that crash on launch. Plasma-integration bugs ruin the function of Nextcloud desktop, Kasts, Monero-gui.
Clearly it’s not unusable for everyone. Based on that description of the symptoms of the problems you’re having, it sounds like your system is deeply misconfigured or missing packages. I’d recommend reaching out to your distro for support.
This assessment is after reaching out to the distro. I’m just using vanilla Arch, installing nvidia drivers and plasma with pacman which should pull all dependencies. The problem seems to be the QT plasma-integration. I’ve done all the troubleshooting.
Can you share the URL of the bug report you submitted to track this issue? I’ll look into it to the best of my ability.
Thanks Nate. Sorry to be difficult/aggressive. This has just consumed so much time.
Arch bbs discussion of issue and troubleshooting:
Closed kasts report:
Closed nextcloud-desktop report:
Thanks Ben. I’ll investigate and post the results in https://bugs.kde.org/show_bug.cgi?id=466804.
Ultimately I suspect this is a bug in your graphics card or its drivers, though.
Very well possible. But here I am stuck with proprietary nvidia drivers.
Yes, that’s often the way it is. In this case, because money has changed hands and you’ve paid for hardware and some level of support for it, I’d say it’s worth reaching out to that vendor about the issue. If they aren’t able to provide any, it may be worth reconsidering that vendor for future purchasing decisions.
The links to the cursor tutorial do not work https://develop.kde.org/docs/extend/cursor/