28

The title says it all. I know that this issue was first raised when KDE 4.0 came out, with the intention of eventually incorporating this feature in the near future. While the stability of the default plasmoids has dramatically decreased the overall number of plasma crashes, however, I feel that the plasmoids should still run under separate processes. There is no such thing as a bug-proof code, and with the availability of more third-party plasmoids in the future, I expect to see more recurring crashes. Additionally, having all the plasmoids run under a single process is, quite frankly, very bad design. It's akin to writing a large C++ application without OOP.

Any thoughts or a potential timeline on this?

Added [TAG] to idea title.

irrdev wrote:Additionally, having all the plasmoids run under a single process is, quite frankly, very bad design. It's akin to writing a large C++ application without OOP.

I agree with you, plasma is not well designed in this aspect.

I think there were two rigth decisions possible, separate processes or plasmoids written only in a script language (javascript, ruby, etc...) to protect plasma.

It's a nuisance having to make a copy of your settings whenever you add, remove or modify a plasmoid because you don't know if it will crash or not. Well, usually crash, but sometimes not.

It's great to have C++-Plasmoids.
It would decrease developer-comfort and speed, if C++-Plasmoids would be removed.
I don't have a lot of crashes in the current 4.69-version. Plasmoids are very small programms. I don't think the overhead of using DBus for each Plasmoid would be useful. And there are yet a lot of Plasmoids just communicating with another application without having possibly buggy functions.

I think there were two rigth decisions possible, separate processes or plasmoids written only in a script language (javascript, ruby, etc...) to protect plasma.

I definitely agree. As a frequenter of the Ubuntu/openSUSE forums, I have come across dozens of KDE users experiencing runtime errors and missing dependencies due to conflicting plasmoid/kde versions. While speed is definitely an issue, I think that going with python would probably have been the best choice for providing a good balance of stabilitiy, speed, and portability. Fortunately, KDE 4.2's support for python and ruby will hopefully increase the developement of third-party plasmoids using either of these languages.

It's great to have C++-Plasmoids.
It would decrease developer-comfort and speed, if C++-Plasmoids would be removed.
I don't have a lot of crashes in the current 4.69-version. Plasmoids are very small programms. I don't think the overhead of using DBus for each Plasmoid would be useful. And there are yet a lot of Plasmoids just communicating with another application without having possibly buggy functions.

More and more Gnome panel applets are written in python and, from my experience, they don't appear to greatly affect performance. As for developer comfort, I personally find python preferable for coding very small programs or widgets. Python (and Ruby) not only result in very readable code, but they can be customized by end-users without recompilation to suit their needs. I think that the benefits outweigh the slight negatives.

Regardless of which language Plasmoids are coded in, I still believe that having Plasmoids as separate processes is extremely beneficial. While creating separate processes would slightly increase total memory usage, I believe that it many cases there would be an associated increase in performance. The processor could move unused plasmoids to the page file, while retaining frequently used plasmoids such as Kickoff in RAM. For example, my processor will sometimes move the entire plasma-desktop process, which is extremely resource hungry, to the paging file while I work with an application, only to reload the plasma-desktop to RAM when I intermittently call it up. At other times, the entire plasma-desktop is forced to occupy my computer's RAM because one or two plasmoids provide real-time updates. With separate processes, the processor would be able to more easily handle calls to individual Plasmoids and delegate system resources accordingly.

Plasmoidviewer uses 5mb of RAM alone so, 10x5 = 50mb of RAM for my current setup of Plasmoids. Plasma currently only uses 9.6mb. This does not scale, is a waste of resources, and will require XEmbed based hacks which are platform specific. Many other problems also exist.

The answer is not "upgrade your RAM". In some cases a perfectly good machine cannot be upgraded. Those users should not be excluded from enjoying KDE.

Developers should not be bound to one programming language.
Some of us (like me) love C++. Some love Python. Some love Ruby.
It's simply wrong to say there should be one right way.
Sometimes there are crashes. Then I remove one Plasmoid and it runs. With seperate processes and just scripting-language a Plasmoid could also crash. What's the difference? Plasma will be restarted automatically. I don't want to have crash-performance but runtime-performance and flexibility.

Perhaps all C++ Plasmoids could be made to use a separate process?

All the main Plasmoids ( Task Manager, System Tray, KMenu / Kickoff ) and the various containments ( Panels, Desktop ) are all implemented in C++. Therefore Plasma crashing with C++ Plasmoids seperated would still be just as bad from the users point of view.

+1 for this...
the making it into separate process also needs a plasma task manager....

It's useless to put all Plasmoids into seperate processes.
Maybe it was the decision of the Lancelot-developers to create a seperate process.
But the other ones should keep the C++-object-model for maximum performance and perfect integration. It would be useless overhead because there wouldn't be a new feature.
What are the possible errors?
-SIGSEGV - simply a bad thing. In the time when Plasma restarts, you should maybe create the bug-report
-uncaught exceptions - maybe there could be an exception-handler for the Plasmoids, then they could be removed and it would be the same like with multiple processes but faster
-Anything else?

How should the seperate-process-Plasmoids work?
A DBus-Plasmoid commnunicating with other processes using DBus-method
-Each simple event would have to be sent via DBus. Serialization would be needed. => slow
-How should the processes communicate with the Korona? Plasmoids must be able to "talk" with otherones. But it could not work with native pointers. Again there is a lot of overhead for communication.
-The process would have to request something like a "virtual pointer" for active communication, then it would be sent to Plasma. Plasma would have to dispatch it. New connection to te other process. Of course the answer and the arguments would have to be serialized... That is simply too complex if you hae a simple plugin-system.
-Also containments and other elementary features would be affected
-It would be very complicate for C++-developers because there wouldn't be any more native communication. Maybe you need an additional KDE- or Qt-resource from Plasma - it would be impossible.

I voted down this, I just don't see the benefits, but the contrary.

I dislike this idea. Plasma as a single process feels nippy as well as integrated - how would individual processes communicate with each other if I e.g. dragged a plasmoid from a panel to a desktop activity? I smell complicated, resource-hungry solutions...

@The User
Just a clarification, Lancelot is not an applet that runs in a different process. Lancelot is a completely separate application (like amarok2 which also uses plasma for its interface). The Lancelot applet (calls the menu methods via d-bus) and Lancelot Parts applet run in the same process as other plasma applets do.

As for the technical side of this discussion, it is practically impossible to do, or to be more precise, it would take too much work with only few benefits (only one benefit, to be honest, an applet wouldn't be able to crash plasma).

I think this idea was posted to avoid crashing hole desktop when some of plasmoid is misbehave. Example from real live is when you have google gadget on your desktop and you disconnected from internet, plasma will crash and it will keep crash till you connect to internet again. I hate this situation but it is happen from time to time. We need some thing to protect plasma from crashing when a plasmoid crashes .