Created attachment 230446 [details] [review]
WorldClock: port to GSettings

Do you think gsetting would also be a good choice to store the list of alarms? Note that here it is a more complex structure and we may need to add new attributes to each alarm in the future. Can gvariant/gsettings be used to store this kind of information in a forward compatible way?

(In reply to comment #2)
> Do you think gsetting would also be a good choice to store the list of alarms?
> Note that here it is a more complex structure and we may need to add new
> attributes to each alarm in the future. Can gvariant/gsettings be used to store
> this kind of information in a forward compatible way?

GVariant is very flexible in this regards. You can use a a{sv} and store what's basically JSON, or you can store (uv) and have a version number coupled with a nested variant whose type can change freely.

So we could have two settings:

 - world-clocks
 - alarms

each one of them an array of string-variant arrays, that is a(a{sv}) if I get the notation right.

For world clocks right now each item would be "location" -> variant returned by gweather. But this would leave us with the possibility to also add other attributes to the setting, like the picture to show.

For alarms each item would contain "time", "label", "repeat", etc

Yes, that's a possibility.

The other way, which is more flexible because it gives you better change notifications, is to make alarms "ao", then store in there a dconf path, referring to a relocatable schema (one with Gio.Settings(schema=, path=)). Then properties of the alarm can be accessed individually, and can be watched with changed::property-name.

The downside of this other way (besides the book-keeping around the ao key) is that dconf-editor fails to associate schemas this way, so you don't see the key until it is changed. The gsettings command line client works fine, though.

Thanks for the interesting suggestion Giovanni.

I think we can stick to the simpler plan for now though

(In reply to comment #4)
> each one of them an array of string-variant arrays, that is a(a{sv}) if I get
> the notation right.

aa{sv} rather


> For world clocks right now each item would be "location" -> variant returned by
> gweather. But this would leave us with the possibility to also add other
> attributes to the setting, like the picture to show.
> 
> For alarms each item would contain "time", "label", "repeat", etc

This is starting to feel only slightly better than how evolution used to store blobs of XML inside of gconf...

I have been pondering this, since storing such "composite" values in gsettings is a bit ugly (that's why I asked Ryan's opinion in the first place), but in the end I decided to go ahead and do it because of the following reasons:

 - this allows us to store serialized GWeather location, which fixes https://bugzilla.gnome.org/show_bug.cgi?id=685433

 - it drops dependency on json

 - it drops quite a bit of code (though I had to do some gymnastic to get pygobject and gweather to cooperate)

 - it is better to do it now while clocks is still a "prototype" (user data gets lost, but I do not want to carry json compat forever)

 - if something better comes along (e.g. gsettings list support, migrating should be easier)


http://git.gnome.org/browse/gnome-clocks/commit/?id=6dba72ecaac2254d7bc214825094bffc75a71ba4


testing and review are much appreciated