[Qt5-feedback] [ExternalEmail] Re: Merging QDeclarative specifics into core QMetaObject

[Craig.Scott at csiro.au]

Sorry to reply to my own post. My fingers are working faster than my brain this morning. ;)

The notion of the "default" property is already covered by the USER keyword in Q_PROPERTY. Is there any reason why QML doesn't simply use that instead of requiring a separate DefaultProperty entry in the classinfo? The relevant page on QML ("Extending QML Functionalities using C++") describes the use of the DefaultProperty entry. Reading over this again, it really does seem like an oversight that this was added instead of re-using the USER property already available in the metaobject system. I suspect that this classinfo feature could be phased out by supporting the DefaultProperty in the classinfo if it is present, but fall back to the USER property if DefaultProperty is not present. In Qt5, I'd then suggest dropping the support for DefaultProperty.


On 15/06/2011, at 10:08 AM, <Craig.Scott at csiro.au> wrote:

> 
> On 14/06/2011, at 10:19 PM, Stefan Majewsky wrote:
> 
>> I was thinking about using QML to define internal datastructures (e.g.
>> as a more powerful alternative to QSettings). While doing so, I came
>> to wonder whether some of QtDeclarative's custom additions to the
>> metaobject framework should be merged into the main macros.
>> 
>> For example:
>>> Q_PROPERTY(QObject* foo READ foo WRITE setFoo NOTIFY fooChanged)
>>> Q_CLASSINFO("DefaultProperty", "foo")
>> 
>> could become:
>>> Q_PROPERTY(QObject* foo READ foo WRITE setFoo NOTIFY fooChanged DEFAULT)
> 
> 
> +1 for this suggestion. In fact, this was how I expected the default property to be defined the first time I was using this aspect of properties of QObject's.
> 
> Note also that the Qt documentation still says that Qt itself does not use anything defined via Q_CLASSINFO except for the ActiveQt extension, but it appears that this is no longer true with QML/QtDeclarative (sorry, can't remember the details of where/how, but I'm sure the relevant people will know the details). If the DEFAULT keyword/classinfo is absorbed into the Q_PROPERTY macro, then at least the Q_CLASSINFO reverts to going back to being just for extensions to Qt or client code. Making this change in the break to Qt5 would seem the right time to do this. If there's going to be a Qt4 --> Qt5 porting tool like there was from 3 --> 4, then it could convert/absorb the Q_CLASSINFO("DefaultProperty",...) stuff into the corresponding Q_PROPERTY macro.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia