[KernelImage] Refactoring Preferences

Pavel Krivanek squeak1 at continentalbrno.cz
Tue Jul 24 07:11:36 UTC 2007


Hi Ralph,

On 7/24/07, Ralph Johnson <johnson at cs.uiuc.edu> wrote:
> Damien said that his main complaint with KernelImage was that it
> didn't have Preferences.  Paval had told him that the reason
> Preferences wasn't in it was because Preferences referenced nearly
> every system in the image, so if you included Preferences, you had to
> include everything else, or else you had a lot of missing references.
> It is not reallly as bad as that, but it does need fixing.

To be correct, the KernelImage does have preferences. The main problem
is that the MinimalMorphic image doesn't have Preference Browser so it
is practically useless for Damien's Squeak-dev image.
In the KernelImage there are all the viewRegistries set to nil so in
case that the Preference Browser would be loaded, all preferences must
be reinitialized.

> Here is how to refactor Preferences.
>
> The preference system is not far from being OK.  The class Preferences
> keeps a database of Preference objects.  Each Preference has a
> PreferenceView.  Apparently Preference is never subclassed, but
> PreferenceView is.  Preferences has only class side methods, and most
> of them create a Preference and put it in the database.
>
> The real problem is that the Preferences system relies on a database
> of preferences stored in class variables.  There is no easy way to
> regenerate this database.  The database depends on the modules that
> are loaded.  So, you can't just write it all out to a file and then
> read it back in again.  It needs to get created dynamically from the
> modules that are loaded.
>
> There is no consistent way that Preferences get created.  Sometimes a
> class initialization method is used, such as in class CurvierMorph.
> Sometimes some other class method creates it, such as in
> HTTPSocket>>addHTTPProxyPreferences.  HaloThemePreferencesView adds
> preferences that use itself.  Worst of all, ScriptLoader adds
> preferences.  ScriptLoader isn't really used any more, but it was used
> to create some past releases and this code got run once and will never
> get run again.  It would be easy to delete this code and then nobody
> would know where the preferences came from.
>
> in fact, there are a lot more preferences than there is code that
> created the preferences.
> It looks to me like some code was written to add preferences, the code
> was run, and then it was deleted.  So, we can't recreate the
> preferences database any more.

You may look into the MinimalMorphicLoader-pk.33.mcz in the
KernelImage SqueakSource repository, class method #setPreferences.
Over there the main MinimalMorphic preferences are set.

> The solution has two parts.  First, find a consistent way to add
> preferences.  I think the easiest way is to say that every class that
> wants to add a preference must define a class method called something
> like #specifyPreferences.  Change all the existing code to do it the
> new way.   You can then regenerate the preference database by sending
> #specifyPreferences to all classes.
>
> That is the easy part.
>
> The hard part is going through the existing preferences and finding
> ones that have no definitions in the existing code.  I imagine you
> could write a script to generate the definitions, though it would take
> some playing around to get it right.  You could run the script to
> generate the code to generate the preferences, then recreate the
> preferences and see if you got the same thing.
>
> Note that this refactoring will add a few methods to a lot of
> different classes.  That way, when those classes are in the image,
> their preferences will be in the image, and if those classes are not
> in the image, their preferences will not be there, either.
>
> -Ralph
>
>



More information about the Squeak-dev mailing list