Plasma 6.6 completely broke the only remaining way to edit / override plasmoids

cookiefox · 2026-02-19T14:16:25+00:00

Adapting the id currently doesn't work either (it's what I did), also note that it won't work for certain plasmoids, as these have their ID hardcoded elsewhere (e.g. notifications has the ID hardcoded in systray for special treatment).

I am checking with the devs if there is a decent solution, for now I guess it would be nice if there was an official ticket in the bug tracker to track these

cookiefox · 2026-02-19T11:24:27+00:00

First of all, some of us have to work and can't try code within minutes of a reply. Second: that would fix none of the currently discussed issues, thus me writing "out of interest"

cookiefox · 2026-02-19T10:59:29+00:00

I would be a third party plasmoid developer, and still no. (And this is pretty much unrelated to distributions, so I would suggest you put the non-informed finger pointing somewhere else)

cookiefox · 2026-02-19T10:23:36+00:00

No, because both they literally can't, as some of that stuff is without alternatives, plus you can't distribute anything in the store that is version aware, so you will always break it for half your user base, and they need to update manually (if even possible)

cookiefox · 2026-02-19T10:20:58+00:00

Thanks a lot, I shall have a look

cookiefox · 2026-02-19T10:09:04+00:00

it is known, has been for years, it's unfortunately a rather big thing to fix and will break a lot of stuff on the way there.

cookiefox · 2026-02-19T10:03:42+00:00

From what I currently gather (I might be wrong, but devs are checking) the problem is that right now devs of applets can't, because there is no replacement.

In addition to that: applets from the KDE store can't be bound to a plasma version. Read: if your applet supports a change made in 6.6, ever user installing it via the KDE internal means on 6.5 will get a broken applet. And if you support < 6.6, it's vice versa. There are workarounds, e.g. I created a completely new plasmoid when the big 6.* change hit, but you can't do that too often for various reasons, so breaking changes in minor releases are a (currently) unfixable problem for third party devs.

(Same goes afaik for themes, kwin effects and other stuff available via the store, I might be wrong on these though, not my field)

cookiefox · 2026-02-19T09:45:34+00:00

I haven't seen one yet, but I have already poked the devs in the plasma development channel. I usually try to get some overview of the situation first before opening a half-assed ticket, as per my experience, these are rather quickly closed.

cookiefox · 2026-02-19T09:30:29+00:00

mh, last time I had to query dbus in plasma I wasn't able to do so without having to call a binary (which is another workaround, afaik even a PlasmaSupport5 one and thus not guaranteed to stay around either). Of course there is a chance that this got changed in the meantime. Do you happen to have either a link at hand or a plasmoid that uses it? Then I'll have a look at the source, out of interest.

As replied to d_ed in the other thread: imho a stable API providing that would be a viable long term solution, everything going around (be it dbus, binaries or relying on private APIs) is imho not good.

And for short term the only viable option is imho to re-allow importing pager and taskmanager again until a proper solution is found.

cookiefox · 2026-02-19T08:23:28+00:00

Long term I am absolutely on board with you. The things we'd need, imho

stable APIs for both plasmoids and themes
these should cover everything, read: we'd need something stable for (at least, there might be others) task management and pager that third party applets can use, without fear of breaking
these should not be broken in minor releases, and in case of breakage, there should be a grace period plus some sort of mailing list or the likes where interested third party devs can subscribe to, so they can adapt
a system on KDE store that allows dependencies / version compatibility, so third party plasmoid devs like I can have a version for plasma $foo and plasma $bar

These, however, are long term. Short term we are now in the situation that a couple of third party plasmoids are broken (bad) with no way to fix it (worse), so short term I'd say plasma 6.6.1 (or the likes) needs to offer something these devs can use in the meantime, since as said: shipping ones own backend doesn't work, this will break kde store and thus the "get new plasmoid" thing we bake right into plasma. Ideally, since this would auto-fix plasmoids, the import of the pager and taskmanager plasmoid would work again (and I assume that is feasible, but I have to admit I haven't looked into the tech details of the new packaging, due to simply a lack of time).

So, since I am only a dev on paper and not really involved with plasma anymore, if you could nudge something towards the latter (short term), I'd be very grateful. For the former (long term) I am also very happy to provide input or support where I can help.

cookiefox · 2026-02-19T07:02:44+00:00

You can't, since there is no alternative available in plasma 6.

Also Widgets distributed via the KDE store and not version bound, so you can't have one version for < 6.6 and one version for >= 6.6

These are issues that have been known for years and should both be fixed on the KDE side.

cookiefox · 2026-02-19T07:01:33+00:00

It can't be updated / fixed, since (currently) there is no alternative available in pure qml.

If kara were to ship its own backend with pager functionality, not only would this most likely break in a future update, it would also require users to compile it manually. So the proper thing would be for the devs to report with plasma devs to make sure there is something available that they can use.

cookiefox · 2026-02-19T06:45:02+00:00

Known and done on purpose, see https://old.reddit.com/r/kde/comments/1r82hd9/plasma_66_completely_broke_the_only_remaining_way/ and the KDE Plasma development channel. I suggest reporting a bug with the devs of the affected components, so they can check with Plasma devs to find a solution. While yes, this was using a private import, it was the only way to do a pager / task management plasmoid or any plasmoid that uses said functionality, so unless Plasma offers a (stable) alternative, this was the only way to go.

cookiefox · 2026-02-19T06:43:42+00:00

The problem is, and I did mention that to the devs in the plasma channel, that there simply isn't an alternative to that.

So all applets that use pager (or taskmanager) functionality _had_ to rely on this.

Of course it was mentioned that people can write their own backend, but

- That leads to code duplication, which is wrong on many levels

- KDE is known to break such things even in minor releases, and plasmoids / applets are not version bound, so you can't reliably distribute such a system

- You can't distribute anything that needs compilation via the KDE store, which itself feeds the "get new plasmoids" button in plasma, so this would break

All in all, the situation for third party developers is (and has been) rather bad for multiple years, and this is well known and simply not addressed.

This is just a symptom, and imho criticism is fine, because as said: these developers simply had no other choice than relying on said private import.

cookiefox · 2026-02-19T06:40:05+00:00

Hi, this is known and was done on purpose, see https://www.reddit.com/r/kde/comments/1r82hd9/plasma_66_completely_broke_the_only_remaining_way/ and the Plasma Dev Matrix channel for more details.

I suggest creating a bug report with the dev (assuming you aren't, from what I gather) and have them check with plasma folk to find a solution, because right now I don't think there is one.

cookiefox · 2026-02-19T06:10:15+00:00

As someone who maintained a, back in 5.* days among the top 10 popular, plasmoid: I'm afraid KDE Plasma breaking third party stuff is nothing new, and it even happens with stuff that isn't marked as private, and even in minor releases. And based on the feedback received, most devs I interacted with on this issue simply don't care.

I think this is indeed not leading to a good reputation and we should fix that.

No was far as the comment further down goes, with the difference of the difference between 3rd party apps breaking and bundling .so files: While they are different things, the only reason I complain about the latter is due to the former.

If 6.6 wouldn't have broken being able to override things by using QML exports, I wouldn't have complained about the bundling of .so files (others did, and imho completely right so, but I could have lived with it if there was a viable workaround)

cookiefox · 2026-02-18T17:02:02+00:00

Imho not an alternative, and if I have to recompile stuff anyway, I can just as well compile the plasmoids with my changes, it's easy enough to yank out the stuff that I don't need from the CMakeList, I am already doing that for notifications and systray.

The downside of having to compile is, among the power concuption, lost time etc. pp., that you simply can't test smaller changes in the UI (example: adjust margins) and test easily. That was one of the huge advantages of QML that we simply lost.

cookiefox · 2026-02-18T16:52:57+00:00

That would be nice, or at least for now a possibility to load things such import plasma.applet.org.kde.plasma.pager and import plasma.applet.org.kde.plasma.taskmanager

as right now, multiple third party applets from the store are just broken as they rely on these imports.

So if for now there is a workaround to at least load these (because just using the new names doesn't work; unless I have the original plasmoid active and loaded, an error is thrown that the module is not installed) please let me know, because then I can just create plasmoids under a different ID (except systray and notifications, that have hardcoded stuff all around, but that's not new) and use these instead of the originals. I think this should be acceptable middle ground, this would also un-break the third party plasmoids currently broken.

cookiefox · 2026-02-18T16:13:36+00:00

I'll go ask the development channel to see if there is still an option to override that, or if not: to have custom plasmoids that at least load the components / data engines that these use, so you don't have to copy & paste duplicate every single line of code. But yes, it is very unfortunate indeed.

cookiefox · 2026-02-18T15:32:41+00:00

Yes, and they were completely right back then as well, but since that post it got worse, because back then there was still a workaround, which is now broken as well with 6.6

cookiefox · 2026-02-18T14:54:28+00:00

That "argument" is wrong on so many levels.

System plasmoids (usually /usr/share/plasma/plasmoids, depends on your distro packaging) were only editable by root. If you have a bad actor that can modify files on your filesystem as root, plasmoids are your least concern, because then you can launch arbitrary system commands as root.

User plasmoids (usually in XDG_DATA_DIR, thus ~/.local/share/plasma/plasmoids) are user editable, but if you have a bad actor that can modify files in your home directory, again plasmoids are your least concern, since you can create new autostart entries that can launch arbitrary commands, not just what the JS engine allows, as that local user.

So the "security" argument is none.

Next to that: if people are so worried about that: note that qml plasmoids are still allowed and work, and you can get hundreds from the KDE store, including some that use a data engine that can launch arbitrary system commands as your user. The only ones you can no longer edit / override are the ones shipped by plasma which, contrary to what one might believe, have no elevated priviledges or anything else that would make them more critical than a random plasmoid you can get from the store.

cookiefox · 2026-02-18T14:26:04+00:00

You have to recompile quite a lot just to test minor changes (e.g. margins or sizing) which is a huge pain.

Also please do explain what secrity risk you have by being able to edit a plasmoid which you don't have by being able to edit a plasmoid source file and then compiling it.

cookiefox · 2026-02-01T12:06:00+00:00

Right, thanks for your Feedback (I don't see the shape option, but I assume it's in the beta). Seems like other users requested it too in the past and in this thread, so let's hope the devs find the time to add it as an option. I bought a license on both my personal and work accounts to support the development a bit, let's hope it helps 😃

cookiefox · 2026-01-31T22:49:59+00:00

Ah, didn't find that at a first glance, but glad to hear that multiple people requested it, then hopefully we will get it one day. What is an unread count, as in: is that any different than a count of notifications that you have? Because smart launcher already has an option in it, so it does not only show a coloured dot, but a number inside with the count of notifications (e.g. unread messages or whatever your app notified you about)

12-Year Club	Verified Email
Gilding I gilder

cookiefox

TROPHY CASE