KConfig XT: kconfig_compiler & friends

[Benjamin Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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.

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!  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.

Some minor points: KConfigDialogManager does not set the widgets for settings 
that are set immutibiliy disabled.  It doesn't track the changes of widgets 
allowing for the dynamic Default and Apply button enabling/disabling.

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.

- -Benjamin Meyer

* The problem being that app settings reading/writing/default etc is done in 
many locations often duplicating work. 
- -- 
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/e3KK1rZ3LTw38vIRApVCAKC8Izbf49DoW138DFaV/ATkUJ6FWgCfe1h/
yPIv3f8vCKWRxBgrSbgnCyw=
=LXl5
-----END PGP SIGNATURE-----