[PyQt] PyQt support for Qt 4.7

[Phil Thompson]

On Fri, 08 Oct 2010 01:08:08 +0200, Giovanni Bajo <rasky at develer.com>
wrote:
> 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>
>> wrote:
>>> On Tue Oct 5 09:36:49 BST 2010, Phil Thompson wrote:
>>> 
>>>> The minehunt example only seems to need support for lists of
QObjects.
>>>> Are
>>>> there any other examples anywhere that have different use cases?
>>> 
>>> I guess that's more or less what it is, though it needs something
extra
>> to
>>> make the QML engine aware of the new TileData type, used as a property
>> type
>>> in the MinehuntGame class, and used as the model that holds the tile
>> data
>>> in
>>> the game. If you can figure out a way to expose homogeneous Python
> lists
>> as
>>> QDeclarativeListProperty containers then that would be cool.
>> 
>> Done that.
>> 
>>> Looking through the examples, there are places where qmlRegisterType
is
>>> used
>>> to add C++ classes to QML as new item types. The "Writing QML
> extensions
>>> with
>>> C++" tutorial in examples/declarative/tutorials/extending is one of
>> these.
>> 
>> ...and there we hit the showstopper.
>> 
>> It looks like it is not possible to publish Python types to QML (and
use
>> 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
> at
>> run time.
> 
> I think that's because they need to construct new instances for that
type
> 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
that
> gets a QMetaObject* and a pointer to a factory function that
instantiates
> 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
the
> pyqt user calls qmlRegisterType(), you fetch the next static object,
make
> it a "delegator" for the user's dynamic object, and register that to
qml. I
> 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...

Phil