KConfig XT: kconfig_compiler & friends

[Waldo Bastian]

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

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. 

I'm very happy with the 1/2 that is solved by KAutoConfig, but I think we 
should have a full solution and we have that now. KAutoConfig stores too much 
configuration information implicitly in the .ui files, that's what I 
considered flawed about it.

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

Technologies like this become much more valuable when they are deployed KDE 
wide, it makes maintenance of applications easier, it's easier to see which 
configuration options are actually used by an application (even if they only 
have three or four options) and you are well prepared when your small 
application grows bigger. Oh, and it saves enums in a way that allows for 
future expansion while maintaining compatibility.

> 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

The benefits increase when the complexity of the application increases, yes. I 
don't think that's a reason not to use it for smaller applicatioons though.

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

The whole purpose of kdelibs is to provide developers with an easy-to-use 
framework for creating applications. This fits in nicely.

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

My original idea was to adapt KAutoConfig but the differences in approach made 
it difficult to share a single class because the semantics would be rather 
different depending on which of the two approaches was chosen. 

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

KConfigWidgetManager might be more appropriate, I will consider renaming it / 
moving it.

As far as KAutoConfigDialog goes, I think some consolidation is in order 
there. In particular I think that KAutoConfigDialog and KCMultiDialog should 
be consolidated since they basically offer the same functionality although 
based on different technologies. It might be impractical to combine them into 
a single class since the two live in different libraries. Maybe rename 
KAutoConfigDialog to KConfigDialog and let KCMultiDialog inherit from 
KConfigDialog.

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

Since KAutoConfig doesn't offer a complete solution I think it should not be 
part of KDE 3.2 indeed. 

> Some minor points: KConfigDialogManager does not set the widgets for
> settings that are set immutibiliy disabled.

Will look into that.

> It doesn't track the changes 
> of widgets allowing for the dynamic Default and Apply button
> enabling/disabling.

Yes it does. I tested it extensively in kgpg.

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

I see no problems with inclusion in 3.2, the APIs are very much derived from 
KAutoConfig/KAutoConfigDialog so the experience gained with KAutoConfig/
KAutoConfigDialog is very much preserved. I see this as a logical 
continuation of KPrefs/KAutoConfig that consolidates the two in a single 
consistent technology. It's important to do that before 3.2 so that we can 
offer developers one single solution for the problem of managing application 
settings.

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SUSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/e/UCN4pvrENfboIRAh5dAKCVTANPTM3x4ie6yuQOoU1AsR4JHQCffUr1
EZ1196aY3yrWkuF1TTntzfs=
=QRFF
-----END PGP SIGNATURE-----