[PyQt] PyQt support for Qt 4.7

[Phil Thompson]

On Fri, 08 Oct 2010 09:05:47 +0100, Phil Thompson
<phil at riverbankcomputing.com> wrote:
> 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...

...unfortunately it doesn't help. QML is checking the static meta-object
to see if a property is valid, so it can only handle properties that are
known at compile time.

Phil