[Development] Settings API for QML

Mark markg85 at gmail.com
Wed Dec 12 11:13:33 CET 2012


On Wed, Dec 12, 2012 at 10:03 AM, Simon Hausmann
<simon.hausmann at digia.com> wrote:
> On Tuesday, December 11, 2012 04:40:50 PM Bache-Wiig Jens wrote:
>> >> I would also consider an even simpler API. How about we introduce a new
>> >> keyword for persistent properties and make it part of the language.
>> >>
>> >> Rectangle {
>> >>
>> >>     id: root
>> >>     persistent property width: 400
>> >>     persistent property height: 300
>> >>
>> >> }
>> >>
>> >> What this means is that the application will automatically store its
>> >> persistent properties on exit and recall those properties on startup. By
>> >> default they would be initialised to the bound value. It will need some
>> >> attached properties or other meta data to override default storage
>> >> locations etc. And we also need to enforce id's to keep values unique
>> >> per qml file.
>> >>
>> >> Jens
>> >
>> > Interesting idea, but isn't that a recipe for horror if you ever want to
>> > change the structure of your application? To make it possible to keep
>> > your application settings if you change your application structure, you
>> > will need to set those attached properties. A default generated value
>> > will not suffice. That either leads to forcing users to set it if they
>> > use the persistent keyword, or leading them into big trouble with
>> > application maintenance in the future. Neither sounds attractive.
>>
>> You certainly have a valid point and I agree that the persistent property
>> will need an explicit name. There are several ways we could try to amend it
>> though:
>>
>> Using special syntax:
>>
>> Rectangle {
>>     persistent property int width: ["application.width", 400]
>>     persistent property int height: ["application.height", 400]
>> }
>>
>> Or perhaps get rid of the keyword altogether and just do:
>>
>> Rectangle {
>>     property int width: Qt.storedProperty("application.width", 400)
>>     property int height: Qt.storedProperty("application.height", 400)
>> }
>
> I think a dedicated syntax has two distinct advantages over a
> Qt.storedProperty alike approach:
>
>     (1) In a distinct syntax we can avoid loosing the type information and
> instead preserve and propagate it into the settings backend. Preserving as
> much type information as possible is going to be crucial for performance
> optimizations in the future.
>
>     (2) A syntax would allow for sensible group and avoiding repetitive
> patterns in the settings names. In your example writing "application.width"
> and "application.height" is not bad, "application" is repeated only twice. But
> if you think of a real world use-case, then you have "application" repeated
> many many times, which is prone to errors ("application" vs. accidentally
> typing "applcation") and it's not very readable. Therefore I think a more
> explicit syntax is more suitable:
>
> PersistentSettings {
>     id: mysettings
>     group: "org.qt.examples.myapp.geometry"
>     property int width: 800
>     property int height: 600
> }
>
> Rectangle {
>     width: mysettings.width
>     height: mysettings.height
> }
>
>
>
> Simon
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

How about:

This one would be singleton.
PersistentSettings {
    id: settings
    // All properties defined in here are the "global" properties
    property int width: 800
    property int height: 600

    // Perhaps enforce that a GroupSettings item can only be
constructed within the PersistentSettings item in an attempt to
enforce settings to be located in one QML file. Don't know if that's
wise or not. Just brainstorming.
    GroupSettings {
      id: myGroup
      property int width: 800
      property int height: 600
   }
}

Then to use it:
Item {
  width: settings.width
}

To use the group settings:
Item {
  width: settings.myGroup.width
}

Just some brainstorming. I do like this syntax! It looks very easy and
understandable to use.



More information about the Development mailing list