[Kde-bindings] KDE/kdebindings

[Sebastian Sauer]

Richard Dale wrote:
> 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.

oh, interesting view here. From my pov the advantage of the ScriptEngine and 
the way how scripting was integrated in Plasma, is that it was/is(?) possible 
to attach a script to each applet/panel/desktop/etc. even to those written in 
C/C++. The separation allows to extend existing applets/panels/desktops/etc. 
with just any kind of scripting a ScriptEngine does exist for what is imho a 
clever design to earn on the one side a clean separation between them (as in 
a C++ applet doesn't need to know anything about optional scripts and by 
using null-applets/-containments probably even the other way around) and on 
the other does try to provide some common interface to integrate and manage 
(GHNS, upload, configuration, etc.) scripts.

> 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 even would agree there that there are sorts of advantages but for sure also 
disadvantages like going an own way rather then using the common kplugin way 
or like a fixed package-format (ok, those one got addressed already :) and 
probably even more things.
 
> 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.

uh? afaik there are no policies and never where cause it would be the dead of 
any kind of foss-project. guess it's not a matter of 'allowed' (as in 
somebody needs to ok something) but more of 'whats possible' (as in how could 
such a kplugin-based binding be integrated without the need to add dirty 
hacks to plasma itself (what in turn would need such a 'ok' :-) ).

> 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.

to sum it up: What is advanced in JavaScript is pre-beginners in Ruby, hehe :) 
Sorry, failed to resist.