KConfig XT / kconfig_compiler
stefan.nikolaus at stuco.uni-oldenburg.de
Mon Nov 29 16:50:25 GMT 2004
Am Mon, 29 Nov 2004 16:34:37 +0100 hat Waldo Bastian <bastian at kde.org>
>> There are several member functions accepting the configuration object
>> the group name as arguments. How can the configuration entries handled
>> 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
> 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
> no such dependency. I think it might work if we consider the parameters
> the *.kcfg file as a list of all possible parameters, and then use
> (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
> 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
> 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
For each member function that takes a variable group name, we define a
parameter and a corresponding group in the .kcfg file.
... <!-- e.g. entries handled by
... <!-- e.g. entries handled by KToolbar::saveSettings(...) -->
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.
More information about the kde-core-devel