KConfig XT: kconfig_compiler & friends

[Cornelius Schumacher]

On Thursday 02 October 2003 02:34, Benjamin Meyer wrote:
> On Wednesday 01 October 2003 12:17 pm, Waldo Bastian wrote:
> > > Is this stuff right to go in to 3.2?
> >
> > Yes, because otherwise we are stuck with KAutoConfig which is design-wise
> > flawed.
>
> At first I thought you just worded it badly and then I started to look at
> all of the changes, but now I think it was intentional and i'll take that
> comment as a slap in the face.  The problem* which KAutoConfig solves only
> 1/2 of (on the configure dialog side), the other half being a single
> location for default values which kconfig_compiler attempts to resolve. 
> This is a good idea for applications with many options, but for most small
> utilities/games/apps with very few options I see little advantage.  One of
> the apps you converted was kjots which only has five or so options.  Adding
> the files and thus the whole new class seems like drastic overkill and
> bloats up the app, negating all of the savings that moving to use
> KAutoConfigDialog added in the first place.  Now I know that you needed a
> small app to be your guinee pig while getting the compiler up and running,
> but I am just pointing out that in the future only the apps with a large
> number of options really take advantage the your additions

This stuff is not only about duplication of default values, but mainly about 
providing a C++ interface to access configuration data in a type-safe way and 
eliminating the need to use strings as keys which can't be checked by the 
compiler. This makes cleaner, more robust code for all applications using it, 
regardless of the number of config options. KAutoConfig completly ignores 
this aspect.

In addition it makes some exciting new things possible, like a GUI 
configuration editor for system administrators, a GUI designer for 
configuration data and automatically generated configuration dialogs. 
KAutoConfig doesn't even address these things.

> On that topic does anyone else thing that having a compiler, config files,
> more files in kdelibs _just_ so developers don't have to type the default
> value of a setting in two places seem silly to anyone else? For
> applications with a very large number of settings putting them all of the
> default values in one file is a very nice thing to have, but I see no other
> benefit.

As said above, this is not about typing default settings. This is about a much 
more powerful infrastructure for config settings than we had before.

> Your change to KAutoConfigDialog effectively just doubled the code adding
> if statements in the functions to choose the kautoconfig pointer or the
> KConfigDialog manager.  This effectively bypassed all of KAutoConfig (which
> KAutoConfigDialog was written if the name didn't give it away...).   The
> addition of KConfigDialogManager which is pretty much a carbon copy of
> kautoconfig with a few changes to handle kconfigskeleton is a gross bloat
> of kdelibs and confuses the hell out of developers who have yet another
> choice with it.  Also KConfigDialogManager shouldn't have the word Dialog
> in it sense it has nothing to do with Dialogs and isn't even in kdeui! 

Well, KAutoConfigDialog isn't a dialog either.

> Wouldn't it have made more sense it simply modify KAutoConfig to add the
> additional functionality?  If they are both kept in cvs every fix to
> KAutoConfig or KConfigDialogManager will probably have to ported to the
> other class.  Either KConfigDialogManager or KAutoConfig should be removed
> asap or they should be merged.

I agree, KAutoConfig should be removed.

> There is quite a lot of changes and additions with all of this (which you
> yourself state is probably unstable).  The API needs to be polished which
> can't be done in the time for 3.2.  If there is a flaw in the design in
> four months there is nothing that you can do about it sense it wont be able
> to change while keeping binary compatibility. 
> KAutoConfig/KAutoConfigDialog has been in kdelibs sense April and is very
> polished (heck it even has a tutorial!) to the point that most of the
> commits are just doc enhancments. I push to have intigrate post 3.2 when it
> can be done much more cleanly.

Most of the stuff Waldo comitted is in KDE for much longer than KAutoConfig 
(as KPrefs in libkdepim). That KAutoConfig is in kdelibs for some time 
doesn't mean too much. You pushed it in and I regret that I haven't objected 
more strongly back then, but I didn't have the time to back my objections 
with code. The fact that no major application uses KAutoConfig and you are 
the only person working on these classes shows that it isn't accepted by 
developers.

In my opinion it's necessary to have this stuff in 3.2 because it helps to 
consolidate the different approaches of handling configuration data and 
dialogs we currently have in KDE. It makes things simpler for the developer, 
so even if its API isn't perfect yet it's still an improvement over the 
different independent incompatible ways to handle configurations we had 
before.

That said, I agree with you, that Waldo should have given other developers the 
opportunity to comment on his changes before committing them to CVS.

-- 
Cornelius Schumacher <schumacher at kde.org>