[Qt-qml] interfaces for QML Python Bindings

michael.brasser at nokia.com michael.brasser at nokia.com
Wed Oct 6 07:52:38 CEST 2010


Hi,

On 05/10/2010, at 1:55 AM, ext Kristian Mueller wrote:
> Unfortunately the QDeclarativePropertyMap can not be used for the task,
> as we are proxying real python objects to QML (e.g. resolving objects as
> attributes of objects when they are requested, etc.). Do you have any
> idea, how we could access QDeclarativeOpenMetaObject without waiting for
> 4.8?


QDeclarativeOpenMetaObject is a convenience subclass of QAbstractDynamicMetaObject (in qobject_p.h). Both of these are exported classes in private headers, so handling them in the same way you are handling script engine access should be possible (i.e. using the private headers). You could alternatively keep a copy of either of these classes in your source tree (you'd probably also want a copy of QMetaObjectBuilder), similar to what is done in Qt Mobility where this functionality is needed, for example:

http://qt.gitorious.org/qt-mobility/qt-mobility/blobs/1.1/plugins/declarative/multimedia/qmetadatacontrolmetaobject_p.h
http://qt.gitorious.org/qt-mobility/qt-mobility/blobs/1.1/plugins/declarative/contacts/qdeclarativeopenmetaobject_p.h

To be clear, both of these methods are "unsupported", and there are no compatibility guarantees if you go either route (as it is all private API). If you do make a copy of either class, the important thing compatibility-wise is the API of QAbstractDynamicMetaObject -- e.g. it shouldn't matter if we change the API of QDeclarativeOpenMetaObject and you don't update your copy, as all that matters in the end is the meta object that is produced (though there might be other "gotchas" that I haven't considered).

Regards,
Michael






More information about the Qt-qml mailing list