RFC: KConfig XT (KDE 3.2)

Benjamin Meyer ben at meyerhome.net
Tue Mar 18 18:36:51 GMT 2003

After reading Waldo's reply to me and thinking about it some more I concluded 
that he was right.  There might be a way to take the best of KAutoConfig and 
KPrefs.  After thinking about the problem and coding it out a few different 
ways I have come to the following conclusion:

To improve the situation beyond what is currently available (default values in 
2 places) the default values must be stored in the application (in 1 place).  
Storing them in an external file for others to look at wont work.  Exporting 
the default will work though.

Rather then storing all of the data in one place like KPrefs or KAutoConfig I 
propose breaking it up a bit and putting the different components where they 
best fit.  KBaseConfig handles the default values, KAutoConfig handles widget 
interaction, and the applications still determines if and when the value 
should be read/saved.

Everything in the system/application must be able to access the default 
values.  An example being KAutoConfig and class foo that calls readEntry() on 
its 10 local variables.  Due to the nature of the data (the default values) I 
propose storing it in KBaseConfig by adding it to KBaseConfig with the 
following two functions:

void setDefaultValues(const QString &group, const QAsciiDict<QVariant> 
const QAsciiDict<QVariant> getDefaultValues(const QString &group) const;

KBaseConfig would get the following "protected:" addition:
QMap<const QString group, const QAsciiDict<QVariant> > defaultValues;

Information such as description, range/validation are not necessary for the 
running of the application and should be provided in an external file that 
does not have to be installed.  Putting it within the binary would only 
increase the binary size at little extra gain.  A possible exceptions would 
be adding the ability for KAutoConfig to output all known widget settings 
descriptions based upon WhatsThis and specified known ranges (such as in 
QSpinBox and QSlider).  In that case the information already exists for the 
users benefit.  I would say simply to have a script that rips the information 
out of the ui file, but not all applications use ui files.  This file should 
be standardized such as "kapprc_info".

Because default values normally are not desired to be saved (use up hd space, 
have to be saved/loaded) there should be a method for extracting all of them.  
Because I am not completely familiar with the KConfig/KApplication code 
currently I submit the following idea (other ideas welcome): a command line 
option --extractDefaultSettings which would tell KBaseConfig to output the 
default values (and type!) every time setDefaultValues are called.  Also 
--extractAllSettings could be added to have KConfigBase output anytime a 
read*Entry() function is called with the name, default, type.  This way as 
the application progresses you can see what all of the widgets (and 
subwidgets) request allowing for very fine tuning of that applications 
behavior.  This file should be standardized such as "kapprc_default".

KAutoConfig would be modified to no longer "read" the default values from the 
dialog, but to simply grab it from kconfig().  This way KAutoConfig simply 
manages the settings<->widgets interaction and nothing more.  This is would 
make KAutoConfig faster the before.

The only downside to the above is that it would bloat every application by the 
size of its default values just like how we store the application about text 
even if it is never used.

The following example from my modification of KTron in exploring this 

  // In ktron.cpp constructor the default values for all of the settings of 
this class
  QAsciiDict<QVariant> defaultValues;
  defaultValues.insert("Name_Pl1" new QVariant(QString("")));
  defaultValues.insert("Name_Pl2", new QVariant(QString("")));	  

// read in the settings for this class using the default values from kconfig
void KTron::readSettings() {
   const QAsciiDict<QVariant> defaultValues =
   QAsciiDict<QVariant> defaultValues;
   KConfig *config=kapp->config();
   playerName[0]=config->readEntry("Name_Pl1", defaultValues["Name_Pl1"]);
   if ( playerName[0].isEmpty() )
       playerName[0] = i18n("Player 1");
   playerName[1]=config->readEntry("Name_Pl2", defaultValues["Name_Pl2"]);
   if ( playerName[1].isEmpty() )
       playerName[1] = i18n("Player 2");

Hopefully I have been clear in my explination.  

-Benjamin Meyer

More information about the kde-core-devel mailing list