Re: Multi-sessioning for GNOME [revisited]

[Colm Smyth <Colm Smyth ireland sun com>]

Havoc,

Your mail clarified your thoughts about "hints", we're much closer than
I thought. I've been using the term 'partition map' on gconf-list gnome org,
lets follow up there only and I'll send a document in the next days to describe
what I have in mind.

I suggest that anyone on gnome-hackers who wants to be involved in
GConf features, take a look at gconf-list; as ideas take shape, we'll
send summary mails to gnome-hackers rather than filling your inboxes
with stuff that our detailed work-in-progress e-mail.

Colm.

>Delivered-To: gnome-private-members gnome org
>Delivered-To: gnome-hackers gnome org
>X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp redhat com 
using -f
>To: Colm Smyth <Colm Smyth ireland sun com>
>Cc: gnome-hackers gnome org, alan redhat com, glynn foster Sun COM, 
gconf-list gnome org
>Subject: Re: Multi-sessioning for GNOME [revisited]
>From: Havoc Pennington <hp redhat com>
>User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>MIME-Version: 1.0
>X-BeenThere: gnome-hackers gnome org
>X-Loop: gnome-hackers gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: <gnome-hackers.gnome.org>
>X-BeenThere: gnome-private-members gnome org
>X-Loop: gnome-private-members gnome org
>
>
>Let's move this to gconf-list -
>
>Colm Smyth <Colm Smyth ireland sun com> writes: 
>> Adding hints to configuration variables is in my view a bad idea:
>
>What I mean by "hints to configuration variables" is that apps would
>be able to affect the partition map. i.e. we would have a partition
>alias "display-dependent" and apps could say "if the user hasn't said
>otherwise, this directory/key should be mapped to the
>'display-dependent' partition, if it exists".
>
>> - requires programming effort in every application
>
>It should be just a file of some kind, not programmatic. Similar to
>the .schemas files. Or it could just be the same file, even though
>this isn't part of the schema.
>
>> - creates configuration data that is forked along fixed meta-variables
>>   (such as display)
>
>That is true.
>
>> - complicates back-end storage
>
>I don't think this is true (the hints are not in the backend, they are
>just an issue of which backend gconfd will use).
> 
>> By separating different sub-configurations into different
>> GConf partitions, apps don't have to maintain 'hints'
>> for individual configuration keys and the ways of partitioning
>> and combining different parts of each user's desktop's total
>> configuration are infinite.
>
>I think I agree here (I agree that we should have a generic partition
>map; I'm not totally convinced of all implementation details,
>e.g. where the map is stored and how, etc.). But I don't think this is 
>in conflict with apps providing a default partition map for their
>keys, and GNOME shipping with some useful partitions such as
>"display-dependent" already set up. That way things work properly out
>of the box. Otherwise the user has to somehow go through the GConf
>database and find all the keys they want to be specific to a display
>and check them off or something.
>
>Colm we should get on the phone sometime and hash out GConf 2.0
>plans. ;-) Maybe not immediately, but before we start working on it in
>earnest.
>
>Havoc
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>

--
Colm Smyth - Sun Microsystems, Ireland - Desktop S/W Engineering
Sun Xtn: 19166    Phone: 353-1-819-9166   Fax: 353-1-819-9200


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers