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