[Qt-qml] QML must love binding programmers

[Renato Araujo]

Hi Kristian great work, its will be a good way to integrate python and
QML will be nice get access to source code.

We in PySide have worked with our DynamicQMetaObject class,  where you
cann add properties, signals and slots on runtime, and we are using
this to make the python -> Qt integration more easy, this is very
helpful to connect signals/slots queued or not. Export python objects
to Qt script language and with QML are current working, you can create
the properties and signal/slot on python and export to QML as a object
and access all  metaData from QML without problem.

Our new target is export a python object as a type to QML, because of
that we need the qmlRegisterType working with dynamic data, maybe the
QDeclarativeOpenMetaObject can solve this problem I will check that,
maybe we are working towards the same goal, and we can join effort to
complete this task.


BR
Renato Araujo Oliveira Filho


On Wed, Oct 27, 2010 at 1:02 PM, Hugo Parente Lima
<hugo.lima at openbossa.org> wrote:
> On Wednesday 27 October 2010 13:58:20 Kristian Mueller wrote:
>> Hi Hugo,
>>
>> we are actually working on something similar here at mixd.tv. Our
>> approach is to map Python objects directly into QML using the Qt Meta
>> Object System (QDeclarativeOpenMetaObject) and by accessing the
>> QScripEngine.
>>
>> We are using QML for our frontend and the business logic is mostly done
>> in Python. Qt is used here for things like:
>>
>>  - Window Creation (+ setting the QML main file)
>>  - TrayIcon stuff
>>  - Window movement
>>  - Drag & Drop Cursor Icons
>>  - Setting the Mouse Cursor Pixmap
>>
>> Some of those could actually be implemented as part of QML.
>>
>> What we'd like our Python <-> QML project to become is a pure QML UI
>> Binding for Python. With the modulatization of Qt maybe only needing a
>> subset of Qt.
>>
>> Our approch is not to control QML from Python, but to allow access to
>> "normal" Python objects from QML. So actually we don't need
>> qmlRegisterType, because we don't need to subclass Qt objects in
>> Python.
>
> But we do need qmlRegisterType, because QML bindings must work the same way Qt
> does, so we need to be able to export Python types to QML.
>
> If nobody does nothing about, PyQt, PySide, Jambi and Qt-Ruby (among others)
> wont be able to fully support QML, the only way I found until now to get this
> working is a bit ugly and add some limitation as the number of types you can
> export to QML.
>
> Regards;
>
>> Our strategy is to keep direct access to QML from Python low. To convert
>> types we are currently using Python-Boost but will remove Boost
>> dependencies over time.
>>
>> We'd see a public release of our code in maybe a month from now.
>>
>>
>> Greetings from Berlin
>> Georg & Kristian
>> --
>> mixd.tv
>>
>> Am Montag, den 25.10.2010, 19:18 -0200 schrieb Hugo Parente Lima:
>> > Hi;
>> >
>> > I'm working on getting Python (PySide) able to export Python types to QML
>> > the same way you can do with C++ types, i.e.:
>> >
>> > class Foo(QObject):
>> >     ...
>> >
>> > qmlRegisterType(Foo, "foo.bar.com", 1, 0, "FooOnQml_huhu")
>> >
>> > I took a look on QtDeclarative sources and faced some issues to integrate
>> > Python or any other language to QML.
>> >
>> > First, QML uses qmlRegisterType<T> function to register a type, this
>> > function just fills a struct with some info and pass it to the depths of
>> > QML, one of these fields is a function pointer, this function pointer is
>> > used as a factory function by QML to create instances of the exported
>> > type T. So what's the problem?
>> >
>> > Using a template function everything can be decided at compile time, so
>> > we have a different factory function for each type exported to QML,
>> > perfect for C++ but Qt bindings doesn't have the information about user
>> > created types at compile time, so we can't have a factory function for
>> > each type created by the user as we have on C++.
>> >
>> > One way to ease the work of people doing Qt bindings to support QML is
>> > adding a bit more info on this factory function, so we can use a Proxy
>> > object to decide what type need to be instantiated.
>> >
>> > I attached a pseudo-patch that implements this idea, pseudo because I
>> > wrote it just to show what changes are needed, if I get a thumbs up
>> > about it I can work, test and create a merge request for it.
>> >
>> > Any comments? Any chances to get it or something like it into the
>> > mainline for Qt4.7.1?
>> >
>> > _______________________________________________
>> > Qt-qml mailing list
>> > Qt-qml at trolltech.com
>> > http://lists.trolltech.com/mailman/listinfo/qt-qml
>
> --
> Hugo Parente Lima
> INdT - Instituto Nokia de Tecnologia
>
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-qml
>
>