[Kde-bindings] Fwd: A help with JS (or maybe also Python) plasmoid

[Sebastian Sauer]

>  I personally would prefer to get something going for 4.1 because I don't
> think we can know what people want

Personally I believe ppl wanna use what they are familar with just like 
myself, while being scripting-junkee, would never to something with 
JavaScript ;)

> In a couple of weeks we are having a hacker sprint in Berlin with a lot of
> the bindings guys (python, ruby, c# and php) and Kross too, and I would be
> very keen on discussing there what to do about Plasma bindings for KDE
> 4.1.

yeah, I am looking really forward to this :)

short brainstorm to collect the 3 different "use-cases" I see there which 
should be imho addressed in plasma (short or long term);

1. ScriptEngine
yes, we need to improve it. Well, I should spend some time to get the 
SuperKaramba-integration improved a bit. Also MacOS-widgets and 
google-gadgets probably need improvments.
Such backends are imho the perfect example why the ScriptEngine is such a good 
idea since they just come with there own API+rendering and only need a way to 
be integrate into the plasma-world what the ScriptEngine is perfect for.
And then there is still those huge advantage I would see if someday someone is 
able to just connect any kind of applet/containment together with a 
ScriptEngine. So, an existing C++ clock could then be manipulated/extended 
with e.g. PHP and imho we are code-wise not so far away from that with the 
current ScriptEngine-logic.

2. Bindings
Per definition it means just bind the current C++ API to the scripting world. 
That's where QtRuby, PyQt, etc. shine through. The big advantages are that 
it's just 1:1 the same API native C++ applets/containments have. Think here 
of sharing documentation, of making porting e.g. a QtRuby applet to C++ damn 
easy, of having just the same power the C++ world has within the scripting 
world. It is like writing native applets/containments while getting right of 
pointers, memory-handling, crashes, static limitations, link-dependencies, 
etc. and providing a high-level language (nope, imho C++ is not but Qt is at 
least partly ;)

3. Out-of-process
This is a case we didn't handle yet at all but it's imho rather important too 
cause of stability++ and cause of mem-leaks--
I don't refer here to e.g. dbus direct but just to being able to somehow let 
applets/containments run in there own process and xembed them somehow + 
connect them to the plasma-process.
imho it makes quit sense specially for external stuff and also for scripting 
(as in "bindings" *and* "scriptengines" like e.g. SuperKaramba which is 
already able to do run out-of-process but misses then the integration into 
plasma). Anyway, that point may have no priority but at least I guess it's a 
good idea to name it ;)