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

[Richard Dale]

On 2/19/08, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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)
Ok, that would lend itself to a visual tool for making the connections
if one does already exist.

> 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.
Yes, I guess the issue is whether or not html/css/javascript as used
in Mac OS X widgets, is consumer friendly enough. Or whether a
'simplified Qt/KDE' would be better, or a visual tool for the UI
better still. It is interesting finding out how non-programmers think
about programming.

> 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.
OK, if you've got rid of the plasma-script dir that's great.

> > > * 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.
Yes, you can't. The only thing I'm talking about is the way that shim
code is invoked - I think it should be from each language specific
extension, after the extension has started. And not have special
plugin api loading code for each plugin api and each language,
including Plasma. Just have a way of starting each possible
scripting/binding language, and let the extension code call back.

-- Richard