One of our researchers at the lab (Tom Tourwe) does the following:

He changed the methods Preferences class>>#initialValuesA" en Preferences
class>>#standardInitialValues, and made a changeset of this change. Filing
in this changeset updates his preferences.

While this is a crude system, it helps our development, since each week
everybody starts out with a fresh image containing the latest changes from
everybody. This could help while a better system is under way.

PS: There seems to be a problem with this approach in the sense that some
preferences are lost after file-in. This indicates that other places update
the preferences. Tom's approach did not take that into account. We should
think of a real singleton user factory that holds these dispersed settings,
and that we can just serialize to disk.

>> From: "Lex Spoon" <lex at cc.gatech.edu>
>>
>> Hrm, I would rather preferences be attached to an image, though.  For
>> instance, I have development images, server images, and an occasional
>> screwball image where I'm playing with something really wierd.  Each
>> image is its own little world, with its own preference settings.
> Such a
>> system is incompatible with global preferences stored in files.
>
> The OpenStep Defaults system, for example, allows hierarchical
> specification of defaults, very similar to preferences.  There is a
> global level which is overridden by a per-application level which is
> overridden by a per-process level taken from the command-line.  The
> first two levels are stored in a per-use defaults database.
>
> A Squeak per-image level would have to be inserted between the
> document and process levels as a "document" level.
>
> Marcel
>
>


--
Roel Wuyts                    Programming Technology Lab
rwuyts at vub.ac.be              Vrije Universiteit Brussel
http://prog.vub.ac.be/~rwuyts
Webmaster of European Smalltalk User Group: www.esug.org