[Qt-qml] interfaces for QML Python Bindings
Artur Souza (MoRpHeUz)
artur.souza at openbossa.org
Wed Sep 29 14:29:50 CEST 2010
Hello Kristian,
On Thu, Sep 23, 2010 at 2:19 PM, Kristian Mueller <kristian at mixd.tv> wrote:
> Unfortunately we need two hooks in the Declarative source code. First we
> need access to the QDeclarativeEngines QScriptEngine. This access is
> necessary to create QScriptValues via QScripEngine::newFunction. We use
> this to make it possible to call Python methods and functions from QML /
> ECMA-Script (via a C++-wrapper function).
> Second, we need access to the QDeclarativeOpenMetaObject to build a
> dynamic ProxyObject, which represents Python objects in QML.
>
> Our current solution is to add a proxy-object implementation and a
> header-file (files are attached) to the declarative source and build our
> "own" version off Qt-Declarative. Of course, we would be very happy if
> we could skip this workaround. Is there any chance that:
> 1. QDeclarativeEngine allows access to its QScriptEngine
> 2. QDeclarativeOpenMetaObject will become part of the Public API
> in the near future?
Right now there are no hooks for this unfortunately as it seems that
more and more people that do "non trivial" stuff with QML needs this
more and more also. Most of the needs I've seen are to integrate
already written JS bindings and rewriting them is not an option (we
know how much does it cost an engineer hour just to rewrite stuff ;)
).
As an workaround for this problem in QML there are two ways of doing
this. One more hackish and the other a little bit cleaner. It's
important to say that one of them is not public API and because of
that that are no guarantees that the header will not change.
1 - First solution: import a private header used by Qt Creator to your project
Qt Creator needs the engine to properly do the debugging of QML and
because of that there is a private header that exports exactly what
you need. As the symbols are exported in Qt, you could simply copy
this private header to your application and use that. Check this
commit for more details:
http://qt.gitorious.org/qt/qt/commit/63c4c0449361ced03838e51d18e1113740f27fa9
2 - Second solution: use QScriptValue tricks to get the engine and
create your own global object
This one is a little bit more "hackish". The trick is to export a
QObject to QML that has a slot that receives a QScriptValue as a
parameter and as soon as possible (maybe using Component.onCompleted
{} ) you call this slot passing whatever you like as a parameter.
On the C++ code you get this parameter and call the engine method
(QScriptEngine *engine() const). This will return to you the engine
itself and you will be able to do "stuff" with the engine :). However,
the rootContext() will be read only and this will limit you.
One solution (hackish too) that we found is to simply change the
global object used by QML. This may lead into problems in the future
but right now it's the only way to go. Checkout the links below to
understand how we do it. The trick is that you can replace the global
object with one that you created and just "copy" everything that the
original one provides to yours and then add to your object what you
need to add and set this new object as the global object of the
engine:
http://websvn.kde.org/trunk/playground/base/plasma/shells/mobile/qmlengine/qmlappletscript.cpp?r1=1179457&r2=1180410
http://websvn.kde.org/trunk/playground/base/plasma/shells/mobile/qmlengine/qmlappletscript.cpp?view=markup
As you see we are doing machinery to work around this problem of QML
that really creates a lot of problems for everyone that needs to
integrate QML with existing code (and there is a lot of Qt code out
there ;) ), and providing a migration path is really strategic for
everybody involved with QML development and IMHO this should be
properly addressed to avoid more and more people to start to finding
"hackish" ways of solving this what will lead into undesired
fragmentation sooner or later.
I hope that this helps you for now and that we can fix this upstream
(Qt itself), which would mean a great step for QML :)
Best regards,
--
-------------------------------------------------------
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
-------------------------------------------------------
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
-------------------------------------------------------
More information about the Qt-qml
mailing list