28

My personal opinion is to write plasmoid mostly in script language, and write performance critical part in c++, then a script binding for c++ code, make them accessable in script side.

To do it now, plasmoid developer need to take care of the script/c++ communication, binding ...

And as my own opinion, we need to standardlize/abstract c++/script interoperability.
hmm... something similar to XPConnect, eg. KPartConnect or KPluginConnect.

It will also solve other problems such as we can't write KControl Module all in script language...(Need to write factory method in c++)

bcooksley wrote: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.

I'm not very experienced on this topic, but isn't there alternatives to run plasmoids totaly separated and on the other hand, as one process? Couldn't there be a chunk of code in a dynamic library, placed in shared memory, that could be accessed by all plasmoids, running in different processes? That would be faster than communicating by dbus or sockets, and it would consume less resources than running plasmoids with all resources loaded.

Is this really a question about which programming language that should be used?

bratwurst wrote:I'm not very experienced on this topic, but isn't there alternatives to run plasmoids totaly separated and on the other hand, as one process?

This isn't possible, at least not with any language / operating system I am aware of.

bratwurst wrote:Couldn't there be a chunk of code in a dynamic library, placed in shared memory, that could be accessed by all plasmoids, running in different processes? That would be faster than communicating by dbus or sockets, and it would consume less resources than running plasmoids with all resources loaded.

Unfortunately, while the library itself can be shared ( it already is ) the state of it cannot be shared between different processes. This is to protect aganist a crash in the library bringing down all attached processes, among other things.

bratwurst wrote:Is this really a question about which programming language that should be used?

In avoiding crashes, yes, it is just a question of using a scripting language instead of the C++ interface. Unfortunately the scripting interface is quite limited, so in quite a few cases, using the C++ interface is required.

@ivan I know, but those parts which could really crash are in a seperate process. The applet itself has never crashed for me.

I think you should simply use your prefered language. Ruby is slower than Python but nobody is forced to use Python. C++ has more crashes and nobody should be forced don't to use it.

But despite to all arguments we have found this thread against or for per plasmoid processes, the conclusion should be that there seem to be many many users that really hate it when the whole plasma desktop crashes, because they "just" placed a broken plasmoid on their desktop.....

This is very intersting and controversial idea at the same time.
On one side ww have a wish that plasma shouldn't crash as a whole when a plasmoid goes out of control.
On the other hand we are told that this is hard if not im-possible to create and it's creation would bring only minute chnages and positive effects.

I wholehartedly agree that Plasma should not crash because one plasmoid crashes.
But on the other hand the solution should be simple, easy and clean.

I think that the best way to resolve this is that plasma / plasmoid sends a crash signal through D-Bus like it's now done with SIGDEV.
But with this differenc that plasma-desktprc should be back-uped in intervals (maybe after every plasmod i aded i a bi too much).
So when curent plasma would crash it would via D-Bus evoked the backed-up version of palsma-destoprc and start it.
So you would't stay with out a desktop then you would get a message that plama crashed and KDE had to fallback to older version of desktop but you can recover your original desktop. Then you would be presented by list of widgets that your crashed desktop contained so that you could remove the "bad" widget.
Then the plasma would switch back to current state.

@Primoz
That's a practical, pragmatic and good idea.

It's not technically possible to have plasmoids in a separate process. The whole basis of Plasma is QGraphicsView, which is a way of managing QGraphicsItems. These items handle their own stacking, opacity etc. and can't be standalone X11 Window objects as would be required to implement out of process plasmoids.

Theoretically it would be possible to create a QGraphicsItem sending events to another process and receiving function calls. But that would be really good.
Isn't there a way to handle dereferencing of null-pointers as exceptions?

I'm not a developer, but this idea came to my head. If its totally impossible, say it

Might be it is possible to have some sort of second layer of plasma over default one to handle tricky/beta plasmoids?
Like a cake. There are plasma desktop, that has panel over it, and there are separate transparent plasma process over them, like a full screen window without window decorations an with z-index of 1.

I'm sure there is a possibility to catch the errors causing SIGSEGV.
There would be overhead but it's nearly nothing in comparison with DBus-communication.
Maybe KDE could provide a standard platform-independent way to enable such exceptions.

I do not believe it would be possible to find which Plasmoid caused the SIGSEGV event. In addition, it would be abnormal behaviour because "My applet just dissapeared!". Crashing allows for bugs to be reported more easily, and for users to take them more seriously.

bcooksley wrote:In addition, it would be abnormal behaviour because "My applet just dissapeared!". Crashing allows for bugs to be reported more easily, and for users to take them more seriously.

Are you kidding? Yes, a statement like this can not be serious. Do you think that X must crash if a single application crash? Well, for plasma the same.

If a plasmoid "dissapeared" plasma should detect it and send a correct warning without a crash, a black screen, a reinit and a lost of current configuration. The first is a professional solution and the second, well, the second is "less professional".

If a plasmoid crash the problem is in the plasmoid and not in plasma and plasma should not be caring and dying with it . With this approach people think that plasma stinks, and do not blame the real culprit, in fact do not know who to blame. If the design of plasma did not provide a system to protect it from evil plasmoids design look as bad as it look.

In my opinion plasma should have independent subsystems.

With GNU/Linux: signal()/sigaction()
With Windows: SEH
So you could handle the crashes in Plasmoids.

I asked a similar question (About why not use scripting languages for all plasmoids) to the plasma mailing list last August and the response (well the most detailed response) I got is here.

To summarise:

* Efficiency: (C++ can be far more efficient for many tasks), a good example of this that i'm thinking of off the top of my head is the "virus" wallpaper in SVN, or the "mandelbrot" one that I've seen screenshots of but can't find :S. Both of these could be quite CPU intensive and it would be fairly infeasible to write these in a scripting language.
This explains why C++ needs to be used in places.

* Dependencies: Other than ECMAScript(Or QtScript or Javascript, depending on how correct you want to be :P) all scripting languages require additional interpreters or VMs to be installed, so no plasmoids in the core KDE modules could use anything but C++ and QtScript without making KDE depend on a separate language being installed (or without core plasmoids not working for those who don't have them installed).
This explains why it's fairly infeasible (for the core plasmoids) to use Python/Ruby/Perl or what have you.

* Also on a kind of related note, having plasmoids use separate scripting languages means that you have to have the interpreters for each of the languages loaded, causing an increase in memory usage (and possibly CPU usage, I'm not too sure about that).

In addition to this, as mentioned above, it would cause a huge increase in RAM usage to run each plasmoid as a separate process, the solution to this isn't to ignore it and expect users to use larger amounts of RAM, it's to be as efficient as possible without being impractical.
Personally I've never had plasma crash on me since 4.2 (and possibly not since 4.1) unless I was running trunk, and even then rarely, the "core" plasmoids all seem to be fairly stable and well-written. Though I'd like if the third party ones were done in a scripting language, since I can't be sure they'll be kept up to date and working.