On Tue, Dec 11, 2012 at 3:30 PM, Thiago Macieira
<thiago.macie...@intel.com> wrote:
> On terça-feira, 11 de dezembro de 2012 15.10.18, Alan Alpert wrote:
>> The two-way binding would be tricky. You don't have a reference to the
>> property and I'd prefer this not be baked into the language.
>>
>> But here's another way of doing roughly that:
>> Rectangle {
>> Persistent.property("width", 400, "application.width");
>> Persistent.property("height");//Last value is the path to
>> store/retrieve from, auto-chosen if left blank. Leave out default and
>> you get 0/null/""
>> Persistent.properties: [ ["height",400], ["width",400,
>> "application.width"] ] //Another possible attached property syntax.
>> }
>>
>> The "Persistent" attached property knows which item it's attached to
>> and the property name, so it can handle everything itself. Like it
>> sets the property on startup and watches the change signal for when to
>> update the persistent data (or just gets it again when it dies).
>
> Please forgive me my lack of QML-fu here. What I'd like to have if I were
> coding such an application would be something like:
>
> - load an element of type PersistentSettings or something
> - declare a list of property names, their types and their settings paths
> this is where I don't know the QML syntax
>
> Then I should be able to use and modify the properties via
> settings.propertyname. If the setting is modified, it might get saved at some
> point. Moreover, if the policy is such that the setting is updated
> synchronously from the backend, the application might react immediately to the
> setting changing (à la GNOME and Mac OS X).
Would you care to sketch out what your PersistentSettings element
would look like in practice?
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).
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" ;) .
--
Alan Alpert
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
