Preferences revamp?

The discussion of Preferences came up in our board meeting last week.
Clearly, Preferences is something that serves Squeak and our
community, due to the amazing range of system configurability they
provide, allowing the system to be tailored to any user-style and
purpose.

However, I feel that the Preferences framework itself does not do
everything I want it to do.  These are the minimum requirements I
think our Preferences system should be able to do:

     1)  it must have a first-class model (which it already does)
     Preferences and Preference.  All of the following requirements must be
     able to be satisfied by talking strictly to this model, (no required
     browsers or sends to outside classes) with uniform API usage
     regardless whether the underlying implementation (Pragma or
     otherwise).
     2)  Answer a collection of all Preference objects representing the
     current system settings.
     3)  Ability to access any single Preference object by its Symbolic
     name.  (We want to maintain the standard Smalltalk "senders" being
     able to easily find users of preferences by their name).
     4)  Ability to ask any Preference its default value, without resetting
     its current value.
     5)  Ability to reset any Preference to its default value, another
     fixed value, or cycle from its current value to its next value.
     6)  Answer a collection of Preference objects representing the default
     system settings, without changing any current Preference settings.
     7)  Answer a collection of the diff between (2) and (6), above,
          without changing the current value of any preferences.
     7.5) Ability for a Preference to answer literal structure (key->value)
     that can be used as input for requirement 7.6.
     7.6) Ability to construct or set a particular Preference to value from
     a libteral specification.
     NOTE:  7.5 and 7.6 are to support ReleaseBuilder
     defaultValueTableForCurrentRelease.
     8)  Ability to Save / Load entire sets of preferences.  But it must be
     a _Logical_ representation of the value so it will work for all future
     Squeaks.
     9)  (Nice-to-have --->) Ability to Save / Load partial sets of
     preferences, leaving remaining preferences unchanged.
      10) Last but not least:  External applications must be able to
     seamlessly and dynamically extend the system with their own
Preference objects and
     have all the above requirements satisfied for them.

Maybe its just because I'm an old-school Smalltalker who prefers to do
everything in objects; but I just have this feeling that the Pragma
implementation we have been using, in spite of its complexity, is
really limiting us, certainly in terms of my above requirements
wishlist, right?  Like, #7, for example...

OTOH, one thing that became very clear from working on the Theme ideas
with Karl and Marcel, is that that is very related to Preferences, and
behaves very much like a preferences system.  I believe it could be
used for the non-visual preferences, too..

Just one addtion: Backwards compatibility is a must-have here. :-)

Best,
Marcel

+1

regarding point 9:  should be possible .


And http://wiki.squeak.org/squeak/518

     "How to lockdown an image for release"

should be reviewed / and if necessary updated.

--Hannes

On 3/7/16, marcel.taeumel <[hidden email]> wrote:

> I would really like to be able to manage my preferences with monticello
> versioning.
> It would be easier to keep images in sync and have other benefits.

You mean you aren't _already_ doing that?  How do you configure your
applications?

I wrote a configuration method to set my app's preferences and version
it with the app code itself..

> Do you save the preferences from the PreferenceBrowser and manage them with
> Monticello ?

I write the code which sets the prefs.  To generate the code from a
button in the preferences browser, we should get requirements 7, 7.5
and 7.6 working.  Its what we've been wanting to do with our releases
for years.  We just need to do it..