RFC: Removal of KAutoConfig / KAutoConfigDialog

[Benjamin Meyer]

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

On Wednesday 12 November 2003 3:52 pm, Scott Wheeler wrote:
> Uhm, question -- after there was pretty much unanimous agreement to remove
> this class why is Benjamin *still* porting things to it?
>
> Was there a secret reversal of opinion that I missed somewhere?
>
> -Scott

As already stated on the cvs mailinglist:

The "port" from KAutoConfig -> KConfig_Compiler is trivial.  KAutoConfig can 
be thought of as a subset of the functionality of KConfig_Compiler.  Why do 
you think it was such a short time to convert almost every app in KDE that 
used KAutoConfig while it took me six months or so to move them from their 
previous custom systems to KAutoConfig in the first place?  The real effort 
is moving the apps to use an automated configure dialog (e.g. what 
kautoconfig and kconfig_compiler have).  Some applications have very 
"interesting" configure systems.  KAutoConfig provides automated configure 
dialogs and only that,  KConfig_Compiler provides it along with more.  So 
apps that I spend a good deal of time moving to KAutoConfig will be very easy 
to move to KConfigXT (~ add xml file, modify two functions).  Either way the 
initial work to an automated configure dialog must be done if you were to 
move an app to KConfigXT.  Concidering that I know KAutoConfig in and out, it 
is in kdelibs and there are plenty of little apps that the authors have asked 
me to port to KAutoConfig I see no reason not to do it or why you wouldn't 
want me to.  By the time we get around to releasing 3.3 ( Can we have the 
timeline be shorter this time? ) they will all be KConfig_XT, moving to a 
automated configure dialog is just one step. 

- -Benjamin Meyer

- -- 
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ssMB1rZ3LTw38vIRAvF4AKCaYB62Ks9KMAfkbOrorXkMxkWCTgCdF88F
0GODrX4yCNRm2xMZjFpM6+o=
=lDWk
-----END PGP SIGNATURE-----