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



_______________________________________________
Qt-qml mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-qml

Reply via email to