[Kde-bindings] GSoc Project: Kross improvements

[Ben Boeckel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Sauer wrote:

> 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 :-/

It should be. The connect stuff is done, disconnect needs to be fixed 
and they need to be made members of objects published to the 
scripts (currently only one object do connect and disconnect is not 
implemented at all). Also, connect fails this way due to the object 
hierarchy being wrong (the published objects are not set as inheriting 
the class which provides connect/disconnect, so the tests for valid 
objects fails). This should be fixed to make connect work. My current 
tests for Falcon have been less than fruitful.

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

That's better in some ways. It allows the script to check what objects 
it received and possibly save itself from errors. Having ready-to-use 
objects would still be nice for Ruby/Python IMO.

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

Hmm. I'd have to look at the Python/Ruby API. Using import and require 
also block having objects with names of system modules (no objects 
named "os" in Python, for example).

>> - - 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 ;)

True. Doing coll->iface()->addObject() and act->addObject() would be 
weird in the code, but it would work. Merging it together for KDE5 could 
be possible then while still offering API/ABI compatability for KDE4 as 
well as the 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.

Yes, changing something at the user-level would be good. I don't use 
the current applications that use Kross very often (KOffice and 
SuperKaramba to my knowledge). However, I do use applications that 
could benefit from integration with Kross. KatePart support for Kross 
scripts would be great as well as Konversation or Kopete scripting 
would be great. Creating Kross plugin bridges for these applications 
would allow cross-platform and cross-architecture plugins to be more 
easily distributed since users could then just download the scripts and 
not have to compile plugins.

- --Ben

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknLGYIACgkQiPi+MRHG3qTmTQCggEn2Hw5VlFUKelS/cooUVhhr
9kUAnjicM00tukb1cC3O2IiJe4Dx7PGO
=N+EX
-----END PGP SIGNATURE-----