[Development] Settings API for QML
jpnurmi at digia.com
Thu Jul 4 14:53:50 CEST 2013
On Jun 22, 2013, at 12:16 PM, Nurmi J-P <jpnurmi at digia.com> wrote:
> On Jun 22, 2013, at 9:02 AM, Hausmann Simon <Simon.Hausmann at digia.com> wrote:
>> You're right, the language extension can be totally separate from settings at the moment. It makes indeed most sense to land things in pieces like you proposed.
>> Alan Alpert <416365416c at gmail.com> wrote:
>> On Fri, Jun 21, 2013 at 2:24 PM, Jeremy Katz <jeremy.k.list at gmail.com> wrote:
>>> On 06/21/2013 09:58 AM, Hausmann Simon wrote:
>>>> I like this, but as a next step I think it would be good to get rid of the manual JS code for saving.
>>>> What about a general syntax of annotating properties? Then settings could be implemented on top by introspecting for properties annotated with settings tags and then save/restore then.
>> My biggest concern about that approach right now is the scope of the
>> change. We can't back out language features as easily as we can a
>> I'd approve adding a Qt.labs.settings element, with the API specified
>> by JP, because it gives us what we need and is the most easily
>> changeable. If we get to annotating properties, we drop the
>> Qt.labs.settings element (after a period of deprecation). We can play
>> around with the backend so long as the QML API works, because while a
>> consistent and reliable on disk format is important for a complete
>> API, for a labs module I'm happy with just the QML API while we figure
>> out other implementation details.
>> The need for this feature seems great enough that people are willing
>> to sacrifice some of the important details in order to get the basic
>> functionality available to QML now (5.2).
>>> I feel like discussion of what this is for has taken a secondary
>>> position to syntax and implementation details.
>> I feel that the "why" discussion was already solved. The "how" is
>> coming up again because it's the sticking point. Here's my
>> understanding of what's needed:
>>> * Is access limited to the application, shared (system wide or multiple
>>> scopes?), or both?
>> Application (although in a more usable format than QtQuick.LocalStorage)
>>> * If shared, does an application receive notification of external
>>> * If shared, does an application have control over when changes are
>>> * Is this targeting a designated storage format, or system (plugin?)
>>> implementation defined?
>> No. The storage format is one of the biggest sticking points because
>> QSettings has no friends anymore. But that's not really useful for the
>> usecase (given that it is not intended for shared settings).
>>> * Is the storage meant to be usable by non-Qt applications?
>>> * Is the storage hierarchical?
>>> To some degree, all of these have been discussed. Have any conclusions
>>> been reached, or are we waiting for a decision by implementation?
>> There are unanswered questions about the implementation, but usually
>> having something that works trumps those whether we're waiting or not
> As Alan clarified, the proposal is to provide a stopgap solution via the labs module.
> I think we all agree that it's currently unnecessarily tedious for QML application developers to bake their own persistent settings solutions. Personally I've done it so far in quite a few QML apps using either QSettings in C++ or LocalStorage in QML.
> While QSettings has its flaws and limitations, it can handle the main use case (simple persistent settings backend without notifications, bells and whistles) just fine. IMHO it's a matter of documenting the limitations and stating clearly that it's not a full-blown publish and subscribe system. Furthermore, keeping the API minimal and QSettings-agnostic might even make it possible to port it over to the mighty new settings system once someone implements it. :)
> J-P Nurmi
By using property aliases the syntax becomes actually quite neat:
import QtQuick.Window 2.1
import Qt.labs.settings 1.0
property alias x: window.x
property alias y: window.y
property alias width: window.width
property alias height: window.height
Fully declarative, and it just... works. Props to Jens for the awesome idea! :)
The initial values can be specified (width, height) or left out (x, y). Settings will be automatically stored when the values change (done lazily, a batch of resize/move events in the above example triggers only one change to QSettings).
Now I'd like to invite interested parties to review https://codereview.qt-project.org/#change,59149.
More information about the Development