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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
