GSettingsList

[Sébastien Wilmet <sebastien wilmet gmail com>]

Hello,

Several months ago, I was interested to work on GSettingsList. I made 
some really basic stuff on github, to see how it works (I've never 
contributed to GLib/GIO):

https://github.com/swilmet/glib
https://github.com/swilmet/dconf

The last thread on this subject was:

http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00065.html

There is also a bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=622126

Now, unfortunately, I don't have time to continue this project. Here is 
my notes, hope it can be useful.

Warning: I worked on this before the introduction of the new 
GSettingsSchema and GSettingsSchemaSource APIs.

=====

First, a little summary of the ideas explained by Ryan in the last 
thread:

- When we create a new item, we write a ".exists" key in the item.  And 
we reset it when we remove the item.  For example 
"/…/profiles/foo/.exists".

- We should be able to have several initial items, each one with its own 
set of initial values (called the full-on approach), and to be able to 
remove an initial item (i.e.  presents in the schema), we write a 
".anti-foo" key.  If both "foo/" and ".anti-foo" exist, we ignore the 
latter.

- There are some lockdown issues, but they can be ignored for the 
first-pass at a new implementation.

- The schema format must be extended to support multiple initial list 
items with different default values.

=====

> This system, when compare with the old one, suffers a major feature 
> regression: it is no longer possible to permute the order of the items 
> in the list.  I'm not sure if anyone cares about this.  I used to think 
> it was important, but I'm happy to abandon/ignore it if nobody complains 
> too loudly.

In some cases the order of the items is important.  For example we can 
imagine that each item is an action which can be called by a shortcut 
like F2, F3, etc and is displayed in a toolbar.  Similar actions can be 
grouped together.  So in this case, the order is important for the user.

One solution would be to write the key ".position" in each item, like 
the ".exists" key (which would be useless then).  Some cases must be 
taken into account:

- If the ".position" doesn't exist, the order is not important for this 
item, and we put it at the end of the list for example.

- In case of conflict, the order is not important between the conflicted 
items.

But I think it's not an important issue, it can be solved afterwards.

=====

My ideas for the implementation.  This supposes that the ".exists" and 
".anti-" keys is the adopted approach.

First, I think it's more logical to create a subclass of GSettings 
called GSettingsList, because functions like get_items(), add_item(), 
remove_item() are specific to lists.  There would be the same 
constructors as in GSettings, but with a check to see if the path 
corresponds to a list in the schema.

A new function must be added to the private backend API to get the lists 
of "valid" and "anti" items.  But this function can be slow for some 
backends.  An idea would be to keep the list up-to-date internally in 
the GSettingsList object.  backend_list() would be called only at 
construction time.  And then the internal list is updated by listening 
some signals from the backend.

The GSettingsList object should emit some signals (item-added, 
item-removed, item-modified, …).

As a first step, the schema can be completely ignored.  So, initially, 
there is no default items (the null approach), and the unique 
information is the name of the items, there is no content.

With this first step, the backend_list() function can already be 
implemented and tested for each backend.  The internal list can be kept 
up-to-date (if an internal list is a good idea), and the different 
signals can be emitted.

Then for the next step, it should be possible to specify the default 
content of a new item, but still keeping the null approach.

And finally (for the first-pass) support the full-on approach, and the 
order of the items.

=====

For the schema, I think there must be the default content of a new item, 
for example:

	foo = 5
	bar = "auie"
	blah = true

This is the exhaustive content of an item.  If we want to have some 
initial items, we express them as "children" of the default content, 
where we can override some values, for example:

	- initial item 1:
		foo = 4

	- initial item 2:
		foo = 3
		blah = false

=====

So that's my 2 cents. Maybe you thought of a completely different 
approach…

Best regards,
Sébastien

Attachment: pgpvFlip9GSb6.pgp
Description: PGP signature