Hi Ryan,
Let me just dump my thoughts on this based on my experience with g-t. It may
help with your design.
In g-t, the user names a profile and can rename it later. The name can have
arbitrary Unicode characters. Logically it means that the name cannot be used
directly in the conf database, so g-t cleans it up. Moreover, since profile
renames are supported, the conf name for a new item may already be taken. Say:
- User creates profile Remote Server, it shows up in the database as
profiles/remote-server/
- Later on, use renames Remote Server to Old Server. The database key
remains at profiles/remote-server/
- User creates new profile called Remote Server, the database key
profiles/remote-server/ is taken, so we use profiles/remote-server-2/
It would be immensely helpful if GSettingsList can do the cleaning up and
dup-avoiding part. So, add_item() will in fact get a name *hint*, clean it
[1] up, avoid dup, and return the key name.
Needless to say, the key name is useless for UI use, so at least in g-t we
always have to have at least one non-default key in the profile which would be
its name.
[1] For the actual cleaning, I suggest you transcribe it to ASCII, lower-case,
replace non-alnum with dashes, remove repeated dashes.
Other than that, I know you already know, but is worth stressing: please avoid
magic keys and values if you can :P.
behdad
On 05/13/2010 06:01 PM, Ryan Lortie wrote:
Hi all,
I've been putting off GSettingsList for a while because of a criticism
that vuntz raised during the hackfest. It's a fairly valid criticism
that I'll describe here, along with my thoughts for a solution. This is
a bit of a request for comments and a hopes that the braindumping
process itself will prove to be useful.
If you don't know, GSettingsList is a way to have a list of like-typed
GSettings instances associated with a given parent. For example, you
could store your list of gnome-terminal profiles or Telepathy accounts
using this mechanism.
The API is something like
string add_item ();
void rm_item (string name);
GSettings get_item (string name);
string[] list_items ();
If gnome-terminal had its list of profiles and had Default and
bigfont profiles, the layout in dconf would look something like this:
/apps/g-t/stuff...
/apps/g-t/profiles/
/apps/g-t/profiles/Default/
/apps/g-t/profiles/bigfont/
also, there is a /apps/g-t/profiles/list key. It is a list of
strings: ['Default', 'bigfont'].
What vuntz didn't like (and what I don't like) is that you can remove an
item from the list but still have garbage settings left for it in the
database.
Going forward it makes sense (and I would like) to tie the existence of
a item of the list to the result of calling the directory enumeration
API on dconf (ie: it's impossible to have garbage, because if you have
garbage then it's not garbage, but recognised as a valid list item).
The main issue with this is that it goes somewhat against the dynamic
creation/removing of paths that dconf follows. Consider, for example,
that we create a new profile white that has all the default settings
(as per the schema) to start with. This means that no key in dconf
starts with
/apps/g-t/profiles/white/
which means that white won't show up when we enumerate
/apps/g-t/profiles/.
There are two main solutions here:
1) change how dconf works to support explicit empty directories.
There are a lot of reasons that I don't like this, and I guess I
don't need to explain them. It's also difficult to express in the
file format (but definitely not impossible).
2) Store some sort of /apps/g-t/profiles/.exists key. This is what
my current line of thinking is (and I guess many people are
familiar with this hack from some other semi-related uses).
The idea then is that you bring a list item into existence using
.exists and remove it using the reset call that is implemented by
the backend (which is a recursive directory removal).
=
There are three main unsolved issues here, though. 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.
=
The second issue is how we deal with seeding the default contents of the
list. There are a few approaches that can be taken here.
- null approach: list initially contains zero items.
- this is very easy, but probably insufficient.
- better approach: list initially contains one item where the default
values of that item are taken from the schema for items (ie: the
default values of the initially-existing item are equal to the
default values that would be applied to newly created items)
- maybe a
