RFC KAutoConfig

[Benjamin Meyer]

I have written a class that I would like to include in kdecore.

This class can be found in kdemultimedia/kaudiocreator/kautoconfig.[h,cpp]
If others think it is a good idea possible inclusion in kdecore would be cool.

The basic premise of the class is that you wont have to code the part of the 
settings dialogs that does grunt work (99% or settings code that is actually 
hand coded).  Simply make the ui files and point them to this class and it 
will store/retrieve/default them.

-Benjamin Meyer

P.S. At the suggestion of others I have added the ability to automaticly 
disable widgets that have settings that are immutiable in kconfig.  This is 
something that I heard a solution was being looked for on the list.

P.P.S. I am only subscribed to kde-devel so please CC me.

Straight from the class comment, the full outline of what it does.

/**
 * @author Benjamin C Meyer <ben at meyerhome.net>
 * 
 * The KAutoConfig class provides a means of automaticly retrieving,
 * saving and reseting basic settings.
 *
 * When told to retrieve/save/reset settings KAutoConfig will traverse the
 * specified widgets performing the requested task on all known widgets that
 * haven't been marked as ignore.
 *
 * At this time KAutoConfig supports:
 * QCheckBox, QSpinBox, QLineEdit, QComboBox, QRadioButton*, KColorButton
 * If one of the above widgets needs special treatment it can be specified
 * to be ignored.
 * 
 * *QRadioButton objects will only get saved if it is checked.  The name of 
the
 * settings will not be the object, but the parent's name (i.e. the 
 * QButtonGroup's name)
 *
 * The name of the widget determines the name of the setting.  The initial
 * value of the widget also is the default when asked to reset.
 *
 * This class was created to further follow the DRY principle.
 * DRY - Don't Repeat Yourself
 *
 *   Every Piece of knowledge must have a single, unambiguous, authoritative
 *   representation within a system.
 * 
 * The majority of settings files are ui files wrapped in a KJanusWidget.  
 * They may have a little logic, but a lot of the code is adding the save, 
 * retrieve, and reset functions.  With every new widget many lines of code 
 * need to be added.  This leads to errors and bugs.  From simple bugs like
 * saving two objects to the same setting, to the time spent coding it this 
 * task can and should be automated.
 *   Some areas of duplication include: 
 * -Having the ui files specify default values, a function to
 *  set all the default values and readEntry specify a default value.  
 * -Naming the objects in the ui file the same as the settings.
 * -Simply doing it over and over for every new application.
 * Using KAutoConfig also leads to a nice side effect of smaller binaries. 
 * 
 * In KControl, objects when exiting often asks the user if they want to apply
 * the settings that the user has changed.  To add this functionality by hand
 * quite a bit of code must be added comparing the old and new values.  One
 * simpler way that some have done is simply to watch for change signal's, but
 * this isn't always correct for a user may change a value, but then change
 * it back.  With KAutoConfig saveSettings() returns a bool value if anything
 * has changed.  The best part is that adding the return took less then ten
 * lines of code.
 *
 * The only major downside to this class is that it is almost guaranteed (?)
 * to be slower then the normal implimentaions.  Thus the design of the class
 * is geared towards improving the speed of its operation.
 *
 **/