[Kde-bindings] branches/work/kdebindings-smoke2/csharp

[Aaron J. Seigo]

On Tuesday 19 February 2008, Richard Dale wrote:
> On 2/19/08, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Monday 18 February 2008, Richard Dale wrote:
> > the goal is NOT to provide a complete set of bindings for scripts to go
> > crazy with. why? because that would make it nearly impossible for
> > *average* people to write things. hell, we may as well ask them to go off
> > and learn a "real" language at that point.
>
> Yes, I agree that is very important, and probably much more important
> than wrapping the complete Plasma C++ api in other languages. However,
> I still feel it is a good idea to have both and will carry on working
> on the Ruby and C# plasma bindings for KDE 4.1.

agreed; they can even become ScriptEngines if desired (though necessary, 
depending on what the exact object is) since the ScriptEngine is defined by 
the language key which can be ... anything. so you could have FullRuby or 
whatever as the KitchenSink API version.

> > no, the goal is provide a very well contained and *small* API that is not
> > a 1:1 mapping to all the power and glory that is Qt and C++ and the rest
> > of the world, but a simplified API. ever wonder why i spent so much time
> > doing DataEngine which is simply a shim between plasma components and
> > *real* data models? yeah, because *real* data models are too varied and
> > too complex; they would require tons of bindings all over the place and
> > tons of explanation to the plasmoid writer.
> >
> > instead we have one little set of api (essentially 2 functions, from a
> > script's perspective) that opens the whole world of data to them.
>
> That's the bit a don't understand ('misunderstand' as you say above
> would be the wrong description because I genuinely don't know how that
> would work).

well, i give an example above with DataEngine. instead of providing bindings 
for Solid, Decibel, Sonnet, RSS, weather, KDirOperator, etc, etc, etc... we 
just provide two classes: DataEngine and AbstractRunner.

for DataEngine there are two key methods:

AppletScript::dataEngine(QString) which provides a managed (e.g. ref counted) 
DataEngine object.

DataEngine::connectSource(QString source, QObject *receiver, int time)[1]

in the receiver (e.g. the script or any of the objects created by the script) 
there is the dataUpdated slot that gets called. most Plasma::Widgets come 
with this slot already in place, so it's a simple matter of (in this 
contrived example):

Meter m;
dataEngine("HardwareHealth")->connectSource("CPU Heat", m); 

what's nice is that you can do this for any of the engines and any of the 
visualizations and it Just Works(tm). so by providing access to just a very 
few methods we can open the doors to all sorts of data.

we're about to do the same for Services (things you command or write to; sort 
of the compliment of DataEngine)

this is how we're trying to think of the API in plasma: how to achieve the 
most in the smallest API. this is not only to ease binding, it's also to ease 
the learning curve for those who would make these things and keep it 
reasonably possible to eventually write that GUI Designer i want.

so when we decide we need to wrap a ton of API so people can script plasmoids, 
i think we need to step back and ask ourselves: what are we really trying to 
make possible here? how can we do that economically?

for HTML, we will be wrapping QtWebKit up nicely into a little Widget (all the 
hard work is already done in Qt 4.4) that will make it downright trivial to 
pass it into a script and let the script do cool things with it (e.g. the 
canvas2d api) without having to write shite loads of webkit specific 
bindings.

that has always been the goal and idea behind libplasma: to create clean 
barriers of separation between plasmoid, plasma application and the rest of 
the world.

[1] reduced for brevity

> > * we need a way to provide other data besides the script file that can be
> > accessed by libplasma. leaving this up to each language binder is
> > complete chaos and simply will not work.
>
> My specific objection is to put all the scripts in a single directory
> under kde4/share/apps/plasma-script. That was how it was when I was
> writing the ruby clock example a few months ago. Maybe that has
> changed in which case ignore this comment. I think they should go
> under kde4/share/apps/<applet name> for exactly the reasons you give
> above.

each applet gets its own directory. that's the entire point of packages.

> > * we want to be able to provie a way to have people package up their
> > contents for sharing with others easily (e.g. via a GUI) and
> > Plasma::Package provides that
> >
> > this goes waaaay beyond "load a script and run it". so if you have
> > actual, real problems with it that impact you in actual, real ways please
> > let us know (on panel-devel, not kde-bindings) and we can sort it out.
>
> I was only talking about how a ruby extension inside a KDE plugin
> should be started up. Whether the Ruby extension is for the complete
> C++ api, or for a simple consumer oriented api I think we should use
> the same code.
>
> When a Ruby extension starts it can do api specific initialization. So
> rather than KDE calling the C++ plugin api, and then some scripting
> specific initialization C++ code which in turn then loads a python,
> ruby, c# or javascript interpreter, I think we could have just one
> plugin type for each of these languages. Then put them in kdelibs
> alongside the C++ versions perhaps.

perhaps the purpose of ScriptEngine is not clear. ScriptEngine is there to 
keep the scripting at arms length from libplasma classes. with this approach:

* classes like Applet have very, very few lines of code added to them and they 
are scriptable. how the scripting happens is a complete detail to these 
classes.

* we can have as many scripting implementations as we want. e.g. we can have a 
QScript one as well as a MacOsDashboard one; even if they both use javascript 
under the hood, the API they provide to the scripts may be radically 
different. this becomes an implementation detail seen only by the scripts.

* ScriptEngine also holds all the nice things like the Package. some of these 
things are right now in AppletScript instead of ScriptEngine where they 
belong; that's an artifact of the recent rearrangement of classes and will be 
addressed.

* finally, ScriptEngine manages finding the right implementation, listing what 
APIs are available (the language key), etc.

perhaps you can suggest a way to accomplish the above that doesn't involve a 
C++ shim between Applet, DataEngine, AbstractRunner, etc.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080219/3e1f7fce/attachment.pgp