Plasma 6.1 is due to be released in three days, and lots of attention went into final release readiness activities: QA, bug-fixing, performance profiling, auto-testing, stuff like that. Boring but important! And happily, reviews of the 6.1 beta are, like, really good. So we want to make sure that the final release doesn’t disappoint!
In addition, we’re hard at work on Plasma 6.2, which is now beginning to accumulate features. Major areas of focus are some of the remaining Wayland pain points, including tablet and artist workflows. You can see some progress on that already:
New Features
Added an additional option for how to map the area of your drawing tablet to the area of your screen. It can be useful to have multiple options here, since drawing tablets are as diverse as screens, and their sizes and aspect ratios are unlikely to be identical (Joshua Goins, Plasma 6.2.0. Link):
Added a test mode feature for drawing tablets so you can test your settings (Joshua Goins, Plasma 6.2.0. Link):
Ported the Weather widget to the new API offered by the NOAA weather provider, which unlocked night forecasts in addition to the existing day forecasts (Ismael Asensio, Plasma 6.2.0. Link 1 and link 2)
UI Improvements
You can now wake up a sleeping screen using a stylus (David Redondo, Plasma 6.1.1. Link)
KWin’s Morphing Popups effect has been deleted. While it added a measure of fanciness, unfortunately the way it worked introduced unfixable visual glitches. After multiple attempts to fix them, with a heavy heart we had to admit defeat. Removing the effect fixed six open Bugzilla tickets, one of which had 20 (!) duplicates. Stability beats fanciness. (David Edmundson, Plasma 6.2.0. Link)
Bug Fixes
Scrolling in Elisa’s lyrics view once again works with a clicky scroll wheel mouse (Jack Hill, Elisa 24.05.1. 24.05.1)
Fixed that annoying bug that affected people not using Systemd (or Plasma’s Systemd integration) which would make some but not all Plasma settings fail to get saved properly (David Edmundson, Plasma 6.1.0. Link)
Fixed a bug that could cause Plasma’s “Unify Outputs” screen action to actually disable certain screens instead of making them mirror the existing one (Xaver Hugl, Plasma 6.1.0. Link)
Quickly adapted to the NOAA weather provider’s continued API changes by implementing a quick fix to keep it working for the Weather widget in Plasma 6.1. (Ismael Asensio, Plasma 6.1.0. Link)
Fixed multiple issues causing System Monitor widgets displaying certain types of days to be visually squished when displayed on Plasma panels (Arjen Hiemstra, Plasma 6.1.0. Link)
Fixed a visual glitch that caused flickering when canceling a quick-tile action initiated by dragging a window (Xaver Hugl, Plasma 6.1.0. Link)
When you change the system volume using the slider in Plasma’s Audio widget, the maximum volume in overdrive mode is once again 150%, not 153% (Ismael Asensio, Plasma 6.1.0. Link)
Fixed an issue that could cause XWayland-using apps to freeze for a short period of time after slowly resizing their windows, especially when using screen scaling (Vlad Zahorodnii, Plasma 6.1.1. Link)
In System Monitor pie charts (both in the app and the widgets), text in the center no longer sometimes overflows when it’s very long (Arjen Hiemstra, Plasma 6.1.1. Link)
Other bug information of note:
- 4 Very high priority Plasma bugs (down from 5 last week). Current list of bugs
- 37 15-minute Plasma bugs (up from 33 last week). Current list of bugs
- 205 KDE bugs of all kinds fixed over the last week. Full list of bugs
Performance & Technical
Improved the memory efficiency of Plasma notifications that display images (Fushan Wen, Plasma 6.2. Link)
Automation & Systematization
Added a test to ensure that Plasma panel focus works as expected (Niccolò Venerandi, link)
Added a test to ensure that images in Plasma notifications appear properly (Fushan Wen, link)
Added a test for some more combinations of settings in Plasma’s Clipboard widget, since there are rather a lot of them (Fushan Wen, link)
Added a test to ensure that the camera usage monitor is working (Fushan Wen, link)
Added a test to make sure the keyboard brightness is settable as expected (Fushan Wen, 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
The KDE organization has become important in the world, and your time and labor have helped to bring it there! But as we grow, it’s going to be equally important that this stream of labor be made sustainable, which primarily means paying for it. Right now the vast majority of KDE runs on labor not paid for by KDE e.V. (the nonprofit foundation behind KDE, of which I am a board member), and that’s a problem. We’ve taken steps to change this with paid technical contractors — but those steps are small due to growing but still limited financial resources. If you’d like to help change that, consider donating today!
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!
Adventures in Linux and KDE 
Hi,
The 15′ minutes bugs had piqued my curiosity. Looks like there is a hard core of ~30 bugs that are not easily squashed. I just had a very quick look and in the first 10 I found these:
In my opinion these are not KDE bugs but 3rd party bugs. There are probably more of these. Sure, they are exposed by KDE and they affect KDE, therefore should be monitored. But it is also somewhat unfair to count these bugs as strictly KDE bugs. Not sure if Bugzilla can assign more than one tag per bug these days but to me a subset of these 15′ bugs should also be marked 3rd party.
I would appreciate a blog entry that attempts to create a high level grouping (other than the ones in Bugzilla) of KDE bugs if possible.
Thanks for all the hard work.
LikeLike
It’s quite right that around 30 of those tickets are really hard.
The SVG rendering one is basically a 3rd-party issue, and could plausibly be closed as RESOLVED UPSTREAM, especially in light of recent ongoing efforts to improve SVG rendering in Qt. I may consider doing that.
For System Monitor, there’s more optimization that can be done in the app itself. But yes, the greater avenue for improvement is in Qt itself for that one.
For the session restore issue, it’s plausible for us to do something ourselves, especially in conjunction with 15329. But yes, most likely a new Wayland protocol will simply be needed there.
The autostart issue is not 3rd-party; we simply need to implement the relevant spec.
LikeLike
I would love to see this one instead, it’s a really cool one:
https://github.com/zzag/kwin-effects-sliding-notifications
LikeLike
Oops a brain lag, that’s another story lol
LikeLike
Well done!
LikeLike
KDE Keeps on rocking !
This article made me discover the SystemD KCM. I have installed it to see what it’s about (package kcm_systemd on fedora I suppose), but I can’t find its entry anywhere on System Settings. Any help ? 🙂
LikeLike
Try searching for systemdgenie standalone app, it’s actually what that KCM is. Cool thingie but lacks a good maintainer.
LikeLike
systemd-kcm was deprecated long ago and wasn’t ported to Plasma 6. it was replaced with systemdgenie, a more powerful standalone application.
LikeLiked by 1 person
OK, thank you! I’ll chack that out 🙂
LikeLike
Greetings
Is the discussion around client-side decorations (CSD) versus server-side decorations (SSD) truly a settled issue, or is it a topic that could be revisited in the future?
I recognize the UX challenges associated with CSD. Although the window movement UX in CSD is inferior to SSD, I find that the streamlined interface of CSD offsets this drawback. This might be influenced by my recent experience using macOS for the past five months, where the downsides of CSD have barely been an issue for me.
This makes for an inefficient navigation and scanning of the application, the information architecture is confusing because of duplication and context switching.
When it comes to consistency, GNOME and Firefox seem to integrate well with Plasma, demonstrating that consistency can indeed be achieved across different technologies using CSD.
What are your current thoughts on the topic?
LikeLike
That point on integration is kinda moot though, considering GNOME apps only integrate well because Plasma goes above and beyond the effort to integrate a framework that’s designed not be integrated with anything but GNOME.
LikeLike
CSD windows look very beautiful, but they don’t scale well to even medium-sized apps.
Once you add more than just the essential features, you run out of space to put them really fast with a CSD headerbar window. On macOS this is largely not a problem because of the omnipresent global menu. But without the guarantee of that, there’s no good place to put stuff: an in-window menubar looks awful with CSDs; a crammed hamburger menu quickly becomes unusable when you try to stuff *everything* into it; condensing everything on the CSD headerbar into an icons-only button hurts usability; and adding more toolbars below the CSD headerbar eats up any space savings it might have provided. All this becomes even worse if you even you leave space on the CSD headerbar to show the document title or app name, and if you don’t, then it hurts usability even more.
It’s for this reason that you see GNOME apps are generally very simple and limited, and there’s a trend towards further reduction in functionality by replacing former core apps with smaller, more stripped-down versions (Gedit -> gnome-text-editor, gnome-terminal -> gnome-console, Evince -> Papers). This isn’t a trend that I see making sense for KDE given how we like our apps large and powerful, or at least to be able to grow to that size eventually.
LikeLiked by 3 people
CSD do not imply headerbars but using CSD makes them easy to implement. I believe that this distinction is commonly ignored when discussing this topic.
In macOS powerful applications use a layout similar to what we have in Plasma, for example
So powerful apps could stay as they are now and simpler apps could opt into the headerbar layout
Obvious examples of headerbar candidates in plasma/kde are Systemsettings, KWrite, Dolphin and even Gwenview.
LikeLike
For windows like that, using CSDs doesn’t bring any advantages over what, as you’ve observed, we already have in KDE apps: a bar on top with the typical titlebar buttons and the window title, and a typical toolbar with buttons below that. Literally the only thing not currently possible is making the sidebar visually connect with the top of the window, which is a trendy visual design choice, not something that actually saves any space or improves usability. You can even see how there’s just pointless empty space above the items in the sidebar.
LikeLiked by 1 person
Agreed, the only benefit is having simpler apps like systemsettings and dolphin with a more streamlined interface with the downside of making rearranging windows more challenging.
Anyway, I just wanted to point out that CSD does not imply headerbar and that having CSD allows apps to easily implement a headerbar where/when it makes sense while SSD makes it virtually impossible (dynamic server side decorators are just too painful to implement).
Well, and I guess that having a mix bag of windows layouts could hurt also UX but that’s already the case with Electron, GNOME, Firefox/Chrome, etc.
LikeLike
I don’t like the “philosophy” behind CSD. If you are looking to save vertical space there are many better options. In Plasma, for example you can use the menu bar and title bar (with window controls) embedded in a top panel, and then hide the menu bar when the windows are maximized. Then I don’t see how an application is more powerful when the developers choose which tools will be present in the toolbar (or in the header), instead of the user deciding that. So the only thing worth noting about CSD is that it’s cute, which isn’t bad, but it’s not enough, in my opinion. Lastly, as others have highlighted, CSD is great for simple applications that do one thing. If you use your system to browse the web, view images and videos, etc., CSD looks not only beautiful but also coherent and consistent. But if what you are looking for is to produce content at a semi-amateur or professional level (writing, recording, editing, designing, modeling…) then you have to use applications designed for that. On Linux, for example, they would be libreoffice, kile, krita, gimp, scribus, blender, inkscape, kdenlive, obs and many others. And then you realize that the CSD concept doesn’t fit and the desktop with which you use those real applications looks ridiculously incoherent and inconsistent.
LikeLike
“Stability beats fanciness.”
On that note, please consider fixing the quick launch, which got broken during 5 -> 6 transition: the width icons in quick launch, and width the quick launch bar as a whole, keeps changing depending on the contexts of the taskbar. It is super annoying when you change desktops, since the pager itself also shifts position depending on what is open in each desktop, so you’ll have to keep playing cat-and-mouse game with it: bug 483178
This is a core feature which existed for over 2 decades, and it is disappointing that nobody cares.
LikeLike
In fact it is by definition not a core feature, as it lives in an addons repo. If it were a core feature, it would live in plasma-workspace or plasma-desktop. So indeed you’re right that “nobody cares” — because frankly, it’s niche functionality that’s of little consequence if it breaks.
For something as unimportant as this widget, there is zero chance that some benevolent company will swoop in and put $100,000 worth of engineering effort into polishing it to a mirror sheen; this outcome will only happen because of passionate volunteers. That’s how basically everything in the FOSS world works outside of the big flashy projects.
When you think about it that way, I think it’s actually pretty amazing that we do have so many things that look and work beautifully! It’s a true testament to the power of passionate volunteers. So this is one of those cases where if you’re the one who cares, you’re the perfect person to help out and make it better. Channel that bitterness into productivity!
LikeLiked by 2 people
Nate, I don’t have the option to Reply to your message, so I’m replying here.
Quick launch icons have been a core feature since KDE 1, when I started using it, and it has been in KDE 2 and KDE 3 as well.
Plasma and separation of various things into widgets didn’t come very late until KDE 4. KDE 4 has been a wrong step in various ways, but that’s a different debate. You’re deflecting by saying how plasma separated and packaged quick launch.
Quick launch has been core (or staple, if you prefer) feature of many desktop environments across many OSs since 90s.
I used to contribute to various FOSS projects when I was young with lots of time, without a family or kids. I’m basically too old to deal with the FOSS card “if you don’t like it, fix it yourself”. You were also similarly dismissive about NVIDIA glitching issues on kwin wayland, blaming solely NVIDIA for it, telling me to buy a new computer with AMD or Intel on your blog just a few months ago (luckily, there are people who are more than talk, and have been working to explicit sync). Anyway, I’m currently in transition to switching to macOS. This has been in my mind since the transition from KDE 3.5 to KDE 4, which put many things on a wrong trajectory, and I’m finally acting on it, albeit with some delay.
LikeLike
You can have launcher icons without the Quick Launch widget, which is probably why fixing and improving the widget is a very low priority.
If you’re dissatisfied with Plasma, I’d definitely encourage you to find something else that makes you happier. Life’s too short to put up with tools that don’t fit you well. Best of luck!
LikeLiked by 2 people
Again, can’t reply to your 2nd post so replying to mine instead.
You seem to be referring to “Icon-only Task Manager”, which is a combination of quick launch and taskbar (apparently copied from Windows 10 or 11, whose taskbar had also taken a bad turn starting with Windows 8).
That goes against my 30+ years of muscle memory using computer UIs. Yes, maybe I’m old (and you’re probably around my eldest kid’s age), but that’s also a testament that it doesn’t work as a replacement as you might think. GNOME also used to be nice, then they started breaking everything down, and essentially kept people telling that to either love or leave it. It’s a nice reminder.
LikeLike
The traditional, non-icons-only task manager also lets you put launchers on it in the form of “pinned apps”. If you want to talk about age, this capability has been there for over 16 years (possibly longer, but my knowledge of KDE doesn’t go back that far).
There’s even another option for launchers on your panel that doesn’t involve the Quick Launch widget: just drag them there! You can stick individual launcher widgets on your panel anywhere you like. This capability is also at least 16 years old, and possibly older.
And JFYI, the KDE “Icons Only Task Manager” is designed to offer the UX of the Mac OS Dock, which is exactly 24 years old. Windows 7 also later copied it 15 years ago. None of this stuff is new by any reasonable definition.
I think this is one of those cases where KDE offers so much choice, you didn’t notice that the thing you were doing one way (apparently putting app launchers in a Quick Launch widget on your panel?) could also be done in other ways too–possibly ways that were better, or near identical. Then when the way you were doing it broke — because almost everyone else had long since changed to something else — it was a shock not only to you because it broke, but also to the developers who hadn’t realized that anyone was still doing things in that old way! We got a *lot* of bug reports about this kind of thing during the 5 to 6 transition. It’s the curse of choice.
LikeLike
Awesome to see all of the improvements here!
I am interested that you note Plasma 6.2 will introduce even more Wayland pain-point fixes. I am, of course, all for fixes, but I did have some questions.
Tablet support is a big, big area that Wayland is improving rapidly on and it’s awesome. I am interested in how much of this is a “pure-Wayland” protocol, or if KDE had to implement anything private to accomplish all this work?
To that end I have a broader query: I believe I read before that, understandably, the KDE team is not opposed to introducing private protocols for various features. That means users get features now. I can also see, if I’m reading it correctly, that there are a lot of private KDE Wayland Protocols (They can be seen on wayland.app as well as on KDE Invent). Of course KDE aren’t the only ones, but we’re talking about KDE here 🙂
Private protocols mean Wayland features can be added without waiting for upstream — Great for users, but in the short-term, to me (not an expert, but a curious user) not so great in terms of potential fragmentation. I would like to emphasise that of course I don’t believe KDE are simply being hostile to anyone, this is done to introduce a solution to a problem, although hopefully a shorter-term one.
So my question is: KDE are creating these private protocols to fix issues now. But what are the long-term plans? Is there an overarching goal (even if that goal is, say, a decade from now) to have as many of these features upstreamed into Wayland as possible, or to replace them with newer versions of certain protocols?
Are there things upstream-Wayland have rejected entirely, and that Plasma (or any other Wayland session) will have to implement themselves?
Some protocols in their current incarnation may not be upstreamed but I’m talking about the general spirit. And of course in such a case that Plasma is using a private protocol in the meantime, things can be reworked to use an upstream protocol once it is available.
Perhaps private protocols as they are used by KDE are simply Desktop-Environment-Specific protocols that it is expected that all DEs maintain to some degree?
Essentially, Wayland features and improvements from Plasma are awesome, but not only do I want to see Plasma Wayland succeed, but I want to see Wayland succeed. So I am wondering how much of the Wayland-goodness we’re seeing in Plasma is actually upstream. I am wondering how much is currently only possible with Plasma-specific protocols, and how much is “pure Wayland”.
I guess in a way this is also to gauge Wayland maturity 😉
Side note: I am very aware of how much work the Plasma folks put into Wayland protocol proposals and discussions, you guys are everywhere and all the proposals I’ve tracked over the years seem to have been proposed by KDE. So please understand, I know you guys do lots of hard work and none of this is questioning your decision making, but more a broader question of how much of these Plasma Wayland enhancements are only available to Plasma for now.
LikeLike
Most of those private protocols didn’t come about as a result of upstream hostility, but rather because the only intended users are KDE’s own software–largely Plasma. There’s nothing wrong with this; it’s fully expected and intended for an organization’s system software to communicate with its own compositor using private protocols.
Public upstream protocols mostly exist for the benefit of 3rd-party apps, for whom it would be weird and confusing to have to implement multiple compositors’ private protocols. So we all get together to agree on something we can tell 3rd-party apps to implement support for.
I think we aren’t far from having all the protocols defined at the Wayland level that anyone really needs for typical use cases. With a window icon protocol being merged just last week, the biggest one that sticks out to me is session restore, and for that, a private protocol isn’t practical because we want buy-in from 3rd-party apps. This proposal for more tablet hardware support also looks relevant and important.
LikeLiked by 1 person
Speaking of tablets and pens, a while back I made a post on the forum comparing the touch/tablet experience on KDE to windows to get an idea of how it could be improved
https://discuss.kde.org/t/touch-experience-on-kde-some-rough-ideas/13741
Do you have any opinions on it?
LikeLike
Awesome!! I cannot wait for 6.1 and those rounded corners! It’ll also fix my last, tiny Wayland glitch.
LikeLiked by 1 person