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.sc...@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
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
