Re: libgnome: User level

[Colm Smyth <Colm Smyth sun com>]

I received a direct mail from Martin (clearly alive, well and kicking ;)
who suggested having a desktop-level setting that can be overridden for
specific apps; I think this is the best solution and is actually just
an example of a recurring desirable feature.

To relate this to the common schema I proposed, I want it to be possible
in general to "inherit" common settings into multiple situations but to 
support re-defining them at the desired level of specificity.

For exmaple your user-name/password is probably anonymous/<mail-address> for
most ftp sites, but in some cases you want to override this; e.g.  your
user-name for rlogin/imap/etc.  is probably your global login name, but not
always.

It would be useful to have a GConf API (function) that accepts multiple keys and
that returns the value for the first matching key; this would be an efficient
way to do "setting inheritance". This has been on my do-sometime-list for
longer than I care to remember; now that people are committing to
configuration API's, these niceties could make our lives a bit easier.

In one useful incarnation, this could become a "configuration context" that
identifies a series of GConf directories that allow an efficient search/retrieval
of multiple related settings (like a structure), with the possibility
for data "inheritance".

Here is a somewhat contrived, simplified and definitely fictional API example:

/* a "search-path" for one or more related settings */
gchar *config_context[]={
	"/user",
	"/client-protocols",
	"/client-protocols/imap",
	"/client-protocols/imap/server/my_great_mail_server"
};

/* two settings that occur together, a "pseudo-structure" */
gchar *settings[]={
	"name",
	"host"
};


GSList *mail_settings = gconf_context_get(db, config_context, settings);

The result is a GSList(GConfValue) and the config_context should probably also
be a GSList but you get the idea.  GConf would internally look for the value for
the user's IMAP mail login name at /user/name, /client-protocols/name,
/client-protocols/imap/name and lastly
/client-protocols/imap/server/my_great_mail_server/name (and does
the same for the host setting) in a single API call.

What do you think ;)

Colm.


>Delivered-To: gnome-2-0-list gnome org
>X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp redhat com using -f
>To: Colm Smyth <Colm Smyth Sun COM>
>Cc: michael ximian com, bratsche gnome org, gnome-2-0-list gnome org
>Subject: Re: libgnome: User level
>From: Havoc Pennington <hp redhat com>
>MIME-Version: 1.0
>
>
>Colm Smyth <Colm Smyth Sun COM> writes:
>> To be honest though, it's far more important to think about designing
>> a good user interface than trying to carve up it's features into
>> easy, hard and impossible to understand. If everything is easy and
>> natural, there doesn't need to be such artificial distinctions.
>> 
>> When a feature gets forced into a user interface by jamming a menu
>> option onto a menu or a tab onto an already over-loaded dialog,
>> you can't fix it by just hiding it sometimes; it's always going
>> to be hard to understand and use.
>> 
>> As I have absolutely no idea how to design a UI for use by anyone except
>> myself, I'm all too happy to ask for help from someone who can, like Calum.
>> 
>
>My view is that the advanced user level is basically a dumping ground
>for crack-rock settings to avoid flamewars. ;-)
>
>If we had some way to simply pick the good ideas and delete
>e.g. nearly all the Sawfish or panel options that would be ideal. 
>But I think there would be a lot of complaints if we removed those
>options.
>
>Michael makes a good point that user level should be global for "the
>desktop" (users don't consider panel/WM/FM separate apps) but 
>maybe specific to larger apps like Gnumeric.
>
>Havoc
>
>_______________________________________________
>gnome-2-0-list mailing list
>gnome-2-0-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-2-0-list