[KernelImage] Refactoring Preferences

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[KernelImage] Refactoring Preferences

Ralph Johnson
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.

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: [KernelImage] Refactoring Preferences

Pavel Krivanek
Hi Ralph,

On 7/24/07, Ralph Johnson <[hidden email]> 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
>
>