KConfig XT / kconfig_compiler

[Stefan Nikolaus]

Am Mon, 29 Nov 2004 16:34:37 +0100 hat Waldo Bastian <bastian at kde.org>  
geschrieben:
>> There are several member functions accepting the configuration object  
>> and
>> the group name as arguments. How can the configuration entries handled  
>> by
>> these funtions be described with the KConfig XT framework?
>
> That's the question indeed. The idea is that you can use the groupname as
> parameter and then create a config object for this patrticular group  
> name.
> But as the kdeui.kcfg file shows, there are entries (groups) that have a
> dependency on such parameters but there are also entries (groups) that  
> have
> no such dependency. I think it might work if we consider the parameters  
> in
> the *.kcfg file as a list of all possible parameters, and then use  
> *.kcfgc
> (note the extra c) files to control how we create different configuration
> objects from this and which parameters we actually want to use.
>
> So taking your kdeui.kcfg file as example (attached again for  
> reference), we
> could generate one config object that uses the "configGroup" parameter  
> and
> that includes all options that depend on the "configGroup" parameter,  
> and we
> could then generate another config object that covers all options that
> doesn't depend on the "configGroup" parameter.

Taking my kdeui.kcfg is a bad idea. In the group "configGroup" two  
different member function are merged as the comments should indicate. Even  
more if you uncomment the last entries. Konqueror call these functions  
with "KonqMainWindow" or with "KonqMainWindow Toolbar mainToolbar",  
respectively. So if we split the configuration objects, we have more than  
two. That would be ugly. I prefer one, if possible.
As is, we have one configuration object. But one group which carries all  
the entries of the member functions with variable group name. That's not  
nice.

> That would require a new option for the *.kcfgc files and changes to
> kconfig_compiler to sort out functions based on parameter dependency.
>

Sounds complicated and we have a bunch of configuration objects.

What about defining default values for the parameters passed to the  
configuration object. Some of the member functions already define default  
group names.
For each member function that takes a variable group name, we define a  
parameter and a corresponding group in the .kcfg file.

For example:

<kcfgfile arg="true">
   <parameter name="ConfigGroup1">
     <default>KMainWindow</default>
   </parameter>
   <parameter name="ConfigGroup2">
     <default>MainToolbar</default>
   </parameter>
</kcfgfile>

<group name="$(ConfigGroup1)">
   ... <!-- e.g. entries handled by  
KMainWindow::saveMainWindowSettings(...) -->
</group>
<group name="$(ConfigGroup2)">
   ... <!-- e.g. entries handled by KToolbar::saveSettings(...) -->
</group>

If no parameter is passed to the configuration object, it works on the  
default group. If we want to let it work on a special group, we pass the  
corresponding parameter. In order to set the second parameter, for  
example, without affecting the first, QString:null can be interpreted as  
default value. That should be possible. The advantage is exactly one  
configuration object. The disadvantage is that several parameters may have  
to be passed. It may become confusing which parameter affects which group.

Regards,
Stefan


-- 
Stefan Nikolaus