KDE Plasma 5.5 Beta Presents New Features

[zanny]

plasma's completely broken process model for plasmoids that allows a single plasmoid to block or kill the entire plasma stack.

The lack of well threaded plasmoids is a pretty big oversight I'll wager. It is super insane how almost any desktop behavior (including file IO using kio) can block the plasmashell process. Literally step one when designing a modern desktop shell is "never block the shell ever especially with file IO".

[schmidtbag]

I use my laptop with two external monitors attached through a single mini displayport cable and the lid closed. When electricity goes off and back again I have no signal anymore and I have to restart my laptop using magic sysrq keys. Or let's talk about the unusable KWin with Intel drivers on Broadwell which forces me to use Xrender. I'm using Arch Linux, so everything is "the latest and greatest".

Everything you mentioned sounds more like a hardware and/or driver problem than a DE problem. I find it really hard to believe that switching to any other DE would fix both of those problems; if one of those problems went away, it's probably because you installed something else that you didn't have before. I've been in a similar situation, where I got a new keyboard and the numlock and caps lock LEDs on it wouldn't work. I found a pretty hacky way to get that to function, but on a separate fresh new install of Arch the keyboard worked just fine without having to do anything at all.

[GreatEmerald]

For me Plasma 5 is not buggy at all. The screen problem is a Qt bug and the Broadwell problem is an Intel driver bug.
I couldn't care less about Breeze icons. Oxygen icons are perfect and enabling those is the first thing I do.
The main thing I'm looking forward to now is getting rid of kdebase4-runtime. Only a few things that need packaging to go!

[mgraesslin]

The lack of well threaded plasmoids is a pretty big oversight I'll wager. It is super insane how almost any desktop behavior (including file IO using kio) can block the plasmashell process. Literally step one when designing a modern desktop shell is "never block the shell ever especially with file IO".

eh, the whole idea behind KIO is to have it out of process. If you hit a case where that blocked the desktop shell something went horribly, horribly wrong there. I would even say that's impossible. If you encounter such a problem, please report a bug report.

Concerning the "threading" model of plasmoids. Well it's not working the way you think. In fact Plasmoids aren't supposed to do anything except rendering. The heavy work is done by DataEngines. So moving the plasmoid into a thread doesn't give you anything. Yes I have heard many users saying that this is needed or that it needs to be out of process, but people who actually looked at the architecture don't say that. We had in the past a few blocking D-Bus calls, that shouldn't happen. Unfortunately there are also oddities like just creating a QDBusInterface blocks. That's rather unexpected for a developer. So even if you design your whole application in a non-blocking way, being very aware of the danger, this one call might still block your interface, without you having any clue about it. I investigated such an issue recently. I was cursing the developer over the blocking calls. Then looked into the code and I went "oooooh, it's all perfect, I have never seen better DBus calls" - every single call nicely async and the block in this one call. It needs highly experienced developers to know that as you can see. The best DBus async code I had ever seen was affected by it. So yes, such issues can still be there, we'll find them one by one and kill them. Ideally users would tell us with a good bug report where they hit such a freeze, that makes it way easier than to try to get from Phoronix forum rants where it blocks.

[Kver]

I use my laptop with two external monitors attached through a single mini displayport cable and the lid closed. When electricity goes off and back again I have no signal anymore and I have to restart my laptop using magic sysrq keys. Or let's talk about the unusable KWin with Intel drivers on Broadwell which forces me to use Xrender. I'm using Arch Linux, so everything is "the latest and greatest".

The answer to your problems is right in your statement, you're on Intel graphics. The release statements have specifically pointed out that there's problems with Intel drivers. Mainly this is because Plasma 5 and Qt/QML make much more thorough use of graphics drivers and features (everything is hardware accelerated now), so Plasma is more sensitive to driver issues. This may be even moreso on newer systems, as the newer chips and their software may be teething a bit more.

Unfortunately this means that the driver skeletons need to be shaken out before Plasma 5 will be stable on Intel graphics systems. There's no sense in blaming Plasma for a fault in MESA any more than it makes sense to blame a boat for hitting rocks in the water.

[Luke_Wolf]

Concerning the "threading" model of plasmoids. Well it's not working the way you think. In fact Plasmoids aren't supposed to do anything except rendering. The heavy work is done by DataEngines. So moving the plasmoid into a thread doesn't give you anything. Yes I have heard many users saying that this is needed or that it needs to be out of process, but people who actually looked at the architecture don't say that. We had in the past a few blocking D-Bus calls, that shouldn't happen. Unfortunately there are also oddities like just creating a QDBusInterface blocks. That's rather unexpected for a developer. So even if you design your whole application in a non-blocking way, being very aware of the danger, this one call might still block your interface, without you having any clue about it. I investigated such an issue recently. I was cursing the developer over the blocking calls. Then looked into the code and I went "oooooh, it's all perfect, I have never seen better DBus calls" - every single call nicely async and the block in this one call. It needs highly experienced developers to know that as you can see. The best DBus async code I had ever seen was affected by it. So yes, such issues can still be there, we'll find them one by one and kill them. Ideally users would tell us with a good bug report where they hit such a freeze, that makes it way easier than to try to get from Phoronix forum rants where it blocks.

Except that the process model is a known problem with a suggested fix of making the plasmoids subprocesses to the point where Aaron wrote a blog post a while back defending the single process decision because using subprocesses would be memory intensive, while promising that switching exclusively to QtQuick/QML would save the day. Turns out Aaron was wrong, and that QML did not in fact save the day because it turns out that under plasma 5 if a plasmoid hangs or crashes that it still takes the rest of plasma with it (for much the same reason a bad javascript could take down firefox), an easy example being that until 5.2 if kicker wasn't in list mode as opposed to the full out kicker using it would crash plasma, which AFAICT is why openSUSE changed the default on it.

Which... It's all nice and fine to go for speed over safety when you know your payload is safe, but let's say Plasma Mobile actually takes off for example now you have a whole bunch of third parties whose payloads aren't necessarily going to be, well now you have a problem.

[mgraesslin]

Turns out Aaron was wrong, and that QML did not in fact save the day because it turns out that under plasma 5 if a plasmoid hangs or crashes that it still takes the rest of plasma with it

So if Aaron with all his experience was wrong (just for the record: Aaron did hardly any work on Plasma 5), what makes you think you know better and that multi process model would safe the day? What if we now change the complete architecture and go for "Luke_Wolf told us one process per plasmoid" and it turns out it doesn't help?

To make it quite clear: it wouldn't. It's not a useful idea to go plasmoids in different processes. It wouldn't help anything. Maybe DataEngines in own processes, but not Plasmoids. And on that I hope that you understand that I trust my own experience on the architecture and the one of my peers more than yours. Sorry about that :-) It would be great if you could also assume that we know what we're doing.

[darkbasic]

The answer to your problems is right in your statement, you're on Intel graphics.

Yes I know, strictly it's not KDE's fault. KDE's fault is not being as popular as other DEs, which in turn means not being tested enough by graphic developers. Unfortunately buying a laptop without intel or nvidia graphics is almost impossible nowadays, so we have to live with such problems.
Regarding bug reports: I reported some bugs upstream against Intel drivers but it seems developers are simply not interested in KDE issues and I think there is no reason bothering Martin with issues which are not his fault. My solution right now is XRender and an UPS.

[Luke_Wolf]

So if Aaron with all his experience was wrong (just for the record: Aaron did hardly any work on Plasma 5), what makes you think you know better and that multi process model would safe the day? What if we now change the complete architecture and go for "Luke_Wolf told us one process per plasmoid" and it turns out it doesn't help?

To make it quite clear: it wouldn't. It's not a useful idea to go plasmoids in different processes. It wouldn't help anything. Maybe DataEngines in own processes, but not Plasmoids. And on that I hope that you understand that I trust my own experience on the architecture and the one of my peers more than yours. Sorry about that :-) It would be great if you could also assume that we know what we're doing.

Oh I don't know, the fact that for every other software that has done this, Chromium being a very relevant example that Aaron himself highlighted, it's solved the exact issues that Plasma 5 has (which it inherited from Plasma 1), which is to say crashes and hangs suddenly become isolated to the component that hung or crashed instead of taking down the whole structure. The only problem being that it's slower and more memory intensive to do it this way because processes are heavy... Which was Aaron's rationale against doing it that way. So unless you have something new to add to the discussion, according to Aaron's own words it is a compromise in favour of speed and memory consumption over safety.

Furthermore pray tell exactly how breaking plasmoids out into subprocesses wouldn't isolate crashes and hangs, the reason that plasma 5 crashes is that Plasmoid X does something bad with memory which then causes the OS to terminate the plasma-shell process (whether that's in the QML scene itself or in the data engine, which admittedly in principle these should only occur outside of QML usage, but 'should' is not the same as 'is'), meanwhile if it's in a subprocess and it does something bad the subprocess dies but plasma-shell still runs. Same deal with hangs but either threads or processes should work (These on the other hand can happen in either QML or outside).

And this isn't my idea at all Martin, this is one of the long standing criticisms of Plasma that has enough support for Aaron to have blogged about it, that I just happen to agree with, and is a generally solved problem with many examples in the wild.

Edit: Also differentiating between A plasmoid and the data engine that it uses is a differentiation without a difference, as a plasmoid is a complete program which includes a QML scene and potentially a data engine

[mgraesslin]

Oh I don't know, the fact that for every other software that has done this, Chromium being a very relevant example that Aaron himself highlighted, it's solved the exact issues that Plasma 5 has (which it inherited from Plasma 1), which is to say crashes and hangs suddenly become isolated to the component that hung or crashed instead of taking down the whole structure. The only problem being that it's slower and more memory intensive to do it this way because processes are heavy... Which was Aaron's rationale against doing it that way. So unless you have something new to add to the discussion, according to Aaron's own words it is a compromise in favour of speed and memory consumption over safety.

Interestingly nobody asked for such an approach before Chrome did it that way. Since then it's the glorified solution, because Google does it that way. I personally think it's a very bad choice - especially for a web browser. Rendering a web site should not cause crashers, as that is always a potential remote execution vulnerability. By making only the tab crash, I think priorities are moved the wrong way: away from fixing crashers to oh at least the experience is good.

Furthermore pray tell exactly how breaking plasmoids out into subprocesses wouldn't isolate crashes and hangs, the reason that plasma 5 crashes is that Plasmoid X does something bad with memory which then causes the OS to terminate the plasma-shell process (whether that's in the QML scene itself or in the data engine, which admittedly in principle these should only occur outside of QML usage, but 'should' is not the same as 'is'), meanwhile if it's in a subprocess and it does something bad the subprocess dies but plasma-shell still runs. Same deal with hangs but either threads or processes should work (These on the other hand can happen in either QML or outside).

I have never ever heard of such a situation. If it were, it's a problem in the QML scene to not kill the QML execution before the OOM kills the complete shell. In fact I'm not even sure if we have any more crashers in the Plasmoids. It's mostly crashers in the API we and Qt provide where the crashers happen and not in the plasmoid. Now apply my thinking about the web browser crashers: you shall fix the crashers and not work around them.

Edit: Also differentiating between A plasmoid and the data engine that it uses is a differentiation without a difference, as a plasmoid is a complete program which includes a QML scene and potentially a data engine

Of course there is a huge difference! A plasmoid is just a bunch of QML files which the user can download. A DataEngine is a binary plugin which the user cannot just download. Which in turn means that the plasmoid consisting only of interpreted code cannot crash the plasma shell.