QtScript

Sebastian Sauer mail at dipe.org
Fri Feb 9 16:00:49 GMT 2007


Simon Hausmann wrote:
> This only works if you wrap every class in a QObject, which is not only
> very tedious but also a waste of memory and is slow (remember, QObject
> destruction is still fairly expensive due to the multi-threading support).
> And it means you have to duplicate the entire API. Kross for example
> provides a binding for QColor where every instance is a full-fledged
> QObject...

the kdelibs/kross/core/variant.h where QColor is wrapped is not used and will 
propably removed again in favor of other solutions if noone needs it (e.g. in 
KOffice we have pigment as replacment/extension).
 
> Ideally you want to wrap value based types as close as possible to the
> language or even implement them in the language itself, for example QPoint
> or QSize as structure/object in the language itself and convert to the C++
> type on-demand instead of wrapping every QPoint as QObject...

and that's how it's handled now. Please look e.g. at 
koffice/libs/kross/python/pythonvariant.* . Specialy the for now uncommented 
code how a QDate/QTime/QDateTime got translated into a python datetime 
object. You may also note, that e.g. QPoint, QPointF, QRect, QRectF, QSize, 
QSizeF are not wrapped as QObject ;)
 
> And on top of that I believe you want to reuse as much as possible of your
> existing internal API and use adaptors to slightly adjust interfaces (for
> example use different return types for methods that return references to
> other objects), instead of duplicating your entire existing API, which is
> what you have to do with kross. Just look at kword's scripting plugin to
> see what I mean.

Well, the KWord scripting plugin is still heavy on progress and new classes 
will appear as now existing classes will be removed. Please take a look at 
e.g. the KSpread scripting plugin which is more usuable today but will fgor 
sure also continue to be improved.

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org




More information about the kde-core-devel mailing list