[Development] Settings API for QML

[Thiago Macieira]

On terça-feira, 11 de dezembro de 2012 15.55.52, Alan Alpert wrote:
> Would you care to sketch out what your PersistentSettings element
> would look like in practice?

In a non QML approximant syntax:

Rectangle {
    PersistentSettings {
        id: settings
        property int width path("application.width")
        property int height path("application.height")
        property enum ButtonOrder buttonOrder path("system.buttonOrder")
    }

    width: settings.width
    height: settings.height
    onLoad: {
        /* contrived example to show that you can change settings */
        settings.buttonOrder = ButtonOrder.OkBeforeCancel;
    }
}

> There is the simple QML Type approach, PersistentSettings { ... }
> where an object encapsulates the settings and that's fine. But it's
> fairly plodding, and what I mean by that is that it exposes the
> functionality but doesn't do much work for you. Look at the Qt
> Mobility Publish and Subscribe API for QML:
> http://doc.qt.digia.com/qtmobility/qml-publishsubscribe.html . It
> exposes all the functionality, but you end up writing a
> disproportionate amount of code to get it to work. One element per
> property at Four LoC each just to be able to read it? It's not
> convenient enough to really drop that effort barrier and start using
> it everywhere (mind you, P&S wasn't for your use everywhere
> variables).

Agreed. It needs to be simple, like what I wrote above, if it were not for the 
fact that it violates the syntax.

Maybe we can introduce "property attributes" to QML and use that decoration 
from the C++ side to read the path. C++11 is getting attributes too, so why 
not QML?

> The goal of the in-line approach (possibly implemented with attached
> properties) is that you can add it easily right there. You don't have
> the conceptual hurdle of 'get settings, hook up settings to variable',
> instead you just metaphorically 'annotate' the variable right there
> and it works. The difference is minimal in absolute terms, but in
> theory it crosses a threshold where it's suddenly *so* easy to use
> that it's just used everywhere it could be from the outset. The only
> problem is that right now users first need to get over the conceptual
> hurdle of "What's an Attached Property" ;) .

Indeed, the above could be made even shorter by simply applying the attribute 
directly to the Rectangle properties. The only drawback is that we'd need to 
properly namespace the attributes so that we're able to extend it in the 
future.

Maybe a one-line overhead for the persistent properties like I've shown would 
be acceptable?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/39cb2888/attachment.sig>