RFC: KConfig XT (KDE 3.2)

Waldo Bastian bastian at kde.org
Sun Mar 16 22:55:38 GMT 2003

On Monday 17 March 2003 05:27, Benjamin Meyer wrote:
> On Sunday 16 March 2003 10:42 am, Cornelius Schumacher wrote:
> > On Sunday 16 March 2003 12:58, Benjamin Meyer wrote:
> > > With KAutoConfig
> > > the applications only have to have the default values in two spots.
> >
> > I would think that this is one spot too much. It violates the DRY
> > principle you cite in the KAutoConfig docs.
> I would have to agree, I am open to suggestions to get it down to 1 without
> adding a lot of extra work.  With the default value only existing in 2
> spots maybe a simple #define list would be good (but not exactly elegant).

I think KPref and KAutoConfig can be merged to some extent, they are really 
not that different, KPref maps config-entries to variables and KAutoConfig 
maps config-entries to widgets.

The information that you need (1) is:
config key (group+keyname)
variable name
default value

Now, assume you have a file with meta-information that contains:
config key (group+keyname)
variable name
default value

You can then generate from this information a class such as MyPref that 
derives from a KPref-like class. This KPref class would need to have one 
additional feature, the ability to access info based on variable name in 
addition to the ability to access info based on the variable itself.

Then you can have a .ui designer file that links widgets to the above 
information. It could do so in the way KAutoConfig does now but instead of 
using the widget name directly as the config key, it would use the widget 
name as the variable name. Then it can hook into KPref and let KPref talk 
with KConfig.

Further, we can derive from the meta-information a default config file 
(basically by stripping out the variable name, since that is internal 
information that is of no use to users).

Now we have the design-freedom to chose whether we actually install this file 
or not:

*) We can install it so that KConfig will be able to tell us about our default 

*) Or we can not install it (cq. install it in share/config.doc instead) and 
include the default values in the MyPref class that we generate.


(1) Information that you don't strictly need, but still might want to provide:
short decription
long description
range/validation criteria

bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com

More information about the kde-core-devel mailing list