[PyQt] PyQt support for Qt 4.7
phil at riverbankcomputing.com
Fri Oct 8 09:05:47 BST 2010
On Fri, 08 Oct 2010 01:08:08 +0200, Giovanni Bajo <rasky at develer.com>
> On Thu, 07 Oct 2010 16:34:41 +0100, Phil Thompson
> <phil at riverbankcomputing.com> wrote:
>> On Thu, 7 Oct 2010 00:35:16 +0200, David Boddie <david at boddie.org.uk>
>>> On Tue Oct 5 09:36:49 BST 2010, Phil Thompson wrote:
>>>> The minehunt example only seems to need support for lists of
>>>> there any other examples anywhere that have different use cases?
>>> I guess that's more or less what it is, though it needs something
>>> make the QML engine aware of the new TileData type, used as a property
>>> in the MinehuntGame class, and used as the model that holds the tile
>>> the game. If you can figure out a way to expose homogeneous Python
>>> QDeclarativeListProperty containers then that would be cool.
>> Done that.
>>> Looking through the examples, there are places where qmlRegisterType
>>> to add C++ classes to QML as new item types. The "Writing QML
>>> C++" tutorial in examples/declarative/tutorials/extending is one of
>> ...and there we hit the showstopper.
>> It looks like it is not possible to publish Python types to QML (and
>> the QML import statement) because QML uses a QObject's staticMetaObject
>> instead of calling metaObject(). That automatically limits it to types
>> known at compile time and no way to inject dynamic meta-objects created
>> run time.
> I think that's because they need to construct new instances for that
> at runtime. I can't see how an object could be instantiated through a
> pointer to its QMetaObject instance (let alone a *dynamic* meta object).
> You would probably need to add a different qmlRegisterType() overload
> gets a QMetaObject* and a pointer to a factory function that
> objects of that type.
> Until you agree with Nokia on a design for this, as a temporary
> workaround, you could generate a fixed pool (eg: N=16) of static objects
> that can be registered in place of the dynamic object; basically, when
> pyqt user calls qmlRegisterType(), you fetch the next static object,
> it a "delegator" for the user's dynamic object, and register that to
> think it might be sufficient to duplicate the metaobject information and
> then forward a few functions like invoke().
> It's ugly, but at least it's all internal to PyQt and you can expose the
> correct API to Python users. When you get this fixed with Nokia, you can
> skip all this.
I've adopted that technique (at your suggestion) elsewhere in PyQt. I keep
forgetting about it because it is so ugly :)
I'll have a think...
More information about the PyQt