[PyQt] PyQt support for Qt 4.7

[Giovanni Bajo]

On ven, 2010-10-08 at 11:04 +0100, Phil Thompson wrote:
> 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.

Eww.. I'll see if I can find someone to blame at Developer Days
tomorrow :)
-- 
Giovanni Bajo      ::  Develer S.r.l.
rasky at develer.com  ::  http://www.develer.com

Blog: http://giovanni.bajo.it
Last post: Compile-time Function Execution in D