[Kde-bindings] KDE/kdebindings

[Richard Dale]

On Tuesday 06 May 2008 13:22:43 Arno Rehn wrote:
> Am Dienstag 06 Mai 2008 11:39:23 schrieb Richard Dale:
> > SVN commit 804509 by rdale:
> >
> > * The Plasma ScriptEngine interface is now mandatory for the Applet and
> > DataEngine apis with non-C++ languages. These Plasma Ruby bindings were
> > not designed to be used with the ScriptEngine, so terminate the project.
>
> I wouldn't have deleted it completely. We can implement the ScriptEngine
> interface AND keep the plasma bindings. You can do more with ruby and
> plasma than just scripting applets, and maybe you want to access some API
> that isn't exposed by the ScriptEngine interface..
Aaron's intention is that the only thing you can do with Ruby in Plasma is 
script applets, and that's what the ScriptEngine interface enforces.

I've had an exchange of emails with him and we think about bindings for non 
C++ languages in very different ways, and in fact can't communicate too well. 
I don't think he is wrong, but he is aiming at a different group of people 
perhaps, and is convinced there are all sorts of advantages by going through 
the ScriptEngine api.

I think it is best to wait until KDE 4.2 and see exactly what we are 'allowed' 
to do, by seeing what the QtScript bindings do a as reference implementation. 
My idea has always been that languages like Ruby and C# should be 'first 
class citizens' on the same level as C++, and shouldn't need 'managing' or 
simplifying. If I want a simpler Ruby api, I can write it in terms of the 
full C++ based Ruby api. I always been free to do what I like with KDE 
bindings before, and this is the first time that this kind of policy has been 
imposed.

We can't define signals and slots in Applets, as is not possible without 
overriding qt_metacall() and qt_metaobject(), and those methods aren't in the 
script engine interface. So are we allowed to create a subclass QObject as in 
instance variable in and put the slots and signals we want there? 

In the applet.cpp code, it has callbacks, like this:

void Applet::paintInterface(QPainter *painter, const QStyleOptionGraphicsItem 
*option,
                            const QRect & contentsRect)
{
    if (d->script) {
        d->script->paintInterface(painter, option, contentsRect);
    } else {
        //kDebug() << "Applet::paintInterface() default impl";
    }
}

I don't particularly see what's wrong with autogenerating the callbacks as we 
do in the smoke lib.

The KDE community doesn't actually have any beginner ruby programmers, only 
intermediate and advanced, and so while a dead simple interface is good for 
JavaScript or BASIC, it isn't needed for Ruby.

-- Richard