[Qt-qml] Settings / State Saving proposal for QML

[Alan Alpert]

On Fri, 18 Nov 2011 17:55:10 Abecasis Joao (Nokia-MP-Qt/Oslo) wrote:
> Alan Alpert wrote:
> > On Fri, 18 Nov 2011 01:34:02 ext João Abecasis wrote:
> > > I have a very basic working prototype for a generic Settings API for
> > > QML that I would like to bring up for discussion.
> > > 
> > > The API is pretty minimal, here's example usage:
> > >     Rectangle {
> > >     
> > >         id: main
> > >         height: 480
> > >         width: 640
> > >         color: settings.color
> > >         
> > >         Settings {
> > >         
> > >             id: settings
> > >             property string color: "blue"
> > >             property alias height: main.height
> > >             property alias width: main.width
> > >         
> > >         }
> > >     
> > >     }
> > > 
> > > I pushed the code to a clone of the Desktop Components repository
> > > over on gitorious. There's some further information in the commit
> > > message:
> > > 
> > > https://qt.gitorious.org/~biochimia/qt-components/biochimias-desktop
> > > /commit/c1ac32929065f24783f4d254d1786dce8202b274
> > > 
> > > While this needs further refinement and exploration (e.g., ignore
> > > the fact that it is using QSettings underneath ;-), what do people
> > > around here think of this approach?
> > 
> > The idea is good, but I don't like the use of aliases in the example.
> > If you wanted to arbitrarily save/load properties perhaps an attached
> > object would be more appropriate, something like:
> > 
> > Rectangle{
> > 
> >         height: 100
> >         width: 100
> >         Settings.persist: ["height", "width"] //If saved data
> > 
> > available, sets on creation. Saves data on destruction.
> > }
> > 
> > It's not just the complexities of aliases, the data really is in the
> > Rectangle element and that's where it should be seen to persist - not
> > due to some magic in a Settings element buried randomly in the code.
> 
> How would you handle data that is read from Settings, but not saved
> back? An example is the color element in my example above.

There is no such data if it's pure QML? What usecase would there be to save 
data but never read it back? I could understand defaults and conditional 
loading of course, but these can also be done with attached objects, something 
like one of the below options presumably:

Settings.save: ["color"]
Settings.load: ["color"]
onPropertySaysSo: Settings.load("color");

So you'd have the Settings attached object which can operate on properties, 
saving and loading as required. The problem is identifying this same object 
again the next time the program is run, now that I think about it. But you'd 
have similar problems with multiple Settings{} items - how were you going to 
solve that? I.e. what happens below after a few runs of the application?

Rectangle{
	color: setting.color
	Settings{
		id: setting
		property variant color: "blue"
	}

	Settings{
		property variant color: "red"
	}
}

> The idea here is to provide a way to gather (and save) information from
> a (platform-specific) standard location and be able to use it seamlessly
> in QML applications. The possibility to use aliases is an admittedly
> very cool side effect.
> 
> > If you just want to save data back and forth, the Settings like object
> > works well though. Presumably you'd want to have a way to explicitly
> > save/load the data if you don't want to use the platform backend?
> 
> Well, the way I want it, there should be nothing but a platform-specific
> backend. I don't want this to become a generic file loading/saving
> mechanism.

Even if it's not a generic file loading/saving mechanism you still want a way 
to get the data out of there. JSON-ifying the object could be enough though, 
if it's all properties on the item.
 
> Also, for platforms where this is supported (not with QSettings,
> though), runtime changes to configuration data could be transparently
> fed back to the application.
> 
> > If it ends up like QSettings (I can't just ignore that fact ;) ) then
> > you'd probably want to have groups handled through the object hierarchy,
> > e.g. Settings{
> > 
> >         file: "settings.ini" //You seem to be missing this property ;)
> >         Settings{
> >         
> >                 group: "Alpha"
> >                 Settings{
> >                 
> >                         group: "Beta"
> >                         property int foo: 34
> >                 
> >                 }
> >         
> >         }
> > 
> > }
> > 
> > Would save [Alpha/Beta] foo=34 (or whatever).
> 
> What's the use case for being able to specify a filename? Is it just
> because QSettings can?

... er, yes. It seems I over-estimated the QSettings influence. With the use-
case now stated it seems perfectly reasonable to scrap files and groups.

> > If you don't want to prototype it with QSettings, perhaps you should use
> > the offline storage API like SameGame. It would still be a nice
> > convenience item to automatically store and load properties from SQL.
> > Then you could also prototype it in pure QML.
> 
> I'm looking into some sort of Settings API that can be used from both
> the QML and C++ side. Also, on a platform where settings end up in a
> central location or where there are external means to change the data, I
> want that to remain available and the QML Application to notice those
> changes.

Ah, so that's the usecase! Thanks for sharing ;) . Do you have any more 
concrete examples though? Should SameGame/Snake switch to this for storing its 
highscores, or is this meant for simpler data (and they should stick to 
offline storage)? Are you aiming to supply the same sort of geometry memory as 
QMainWindow has? Or is this just for storing the last state of user controls, 
like their checkbox arrays?

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks