[Kde-bindings] GSoc Project: Kross improvements

[Sebastian Sauer]

Ben Boeckel wrote:
> I am interested in improving Kross. I am creating a strategy/RPG game
> engine which relies heavily upon Kross for its scripting capabilities and
> there are some issues that I have found that I would like to work on
> fixing:
> 
> - - I have seen inconsistencies between the different languages which
> have bridges in their use of connect and disconnect. QtScript is
> different because it does them differently anyways, but the rest should
> have all the common uses for connect and disconnect available. I have
> a patch attached which implements all of the overloads (listed below)
> for the connect() function.

yay, that rocks! Maybe just commit the krossfalcon-patch or is it incomplete? 
One of those cases where I regret that I still don't got unittests done for 
the falcon-integration :-/

[snip]

> qobj.connect(signal, localslot[, type])
> qobj.connect(sender, signal, receiver, slot[, type])
> qobj.connect(sender, signal, receiver, signal[, type])
> qobj.connect(senderreceiver, signal, slot[, type])
> qobj.connect(senderreceiver, signal, signal[, type])
> sender.connect(signal, localslot[, type])
> sender.connect(signal, receiver, slot[, type])
> sender.connect(signal, receiver, signal[, type])
> senderreceiver.connect(signal, slot[, type])
> senderreceiver.connect(signal, signal[, type])

> - - Publishing of objects to the script currently differs between the
> languages supported. JavaScript, QtScript, and Falcon can just use
> published objects while Python and Ruby need to import and require
> the objects, respectively.

The difference here is, that the impot/require-hook in python/ruby is what 
those e.g. QScriptEngine::importExtension() is in QtScript. But this days the 
same can be done by all backends using e.g.
    import kross
    kross.module("forms")
rather then
    import forms
where the first way works the same way on all backends and the second is 
basicly still there for backward-compatibility for older scripts.

> I'm not completely familiar with the API of the
> languages, but I think it should be possible to support setting up global
> variables with the names rather than intercepting import or require
> calls (as my last overview of the code led me to believe).

yeah. The difference is, that using require/import/importExtension the script 
does pull the loadable extension while kjs/kjsembed (javascript) does not 
provide such functionality and only support push (from C++).
 
> - - Rework Kross::ActionCollection to also inherit from
> Kross::ChildrenInterface. K::AC should also support having QObjects
> published through them. In order to publish objects to a branch of
> objects, an object mush be published at every leaf or available to all
> through the Kross::Manager. Personally, I find this hard to work with in
> Sigen since many scripts may need a class and publishing it for every
> script is prone to errors with missing objects and such.

++ :-)
 
> This breaks the current API/ABI, but providing it in parallel could be
> workable until KDE5 I think (though since I think Kross-enhanced
> projects are few outside of KDE, just port them to it, but I understand if
> this is an unworkable solution)

yes, backward-compatibility is the most important thing there. But there is 
always a way to stay backward-compatible while implementing the 
requested/required functionality ;)
 
> - - Forwarding headers. An easy fix, but currently not provided.
> 
> Any feedback would be greatly appreciated.

I would suggest to extend the proposal with something that does provide a 
direct visible solution on application-level. Means, there are applications 
using Kross and there are applications which may plan to use Kross. If the 
proposal does, at least part-time, also try to extend the current Kross-
integration into the app or to provide it to another app, then the proposal 
would provide two advantages; 1. improve kross and 2. improve the choosen 
application. Specially the second part does then offer a direct visible and by 
endusers usuable advantage.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20090325/af66cfda/attachment.sig>