post 3.3 kconfig_xt work

[Aaron J. Seigo]

On Thursday 12 August 2004 09:53, Maks Orlovich wrote:
> > -Better kiosk mode integration, both in disabling widgets that can't be
> > changed and in not storing settings when they don't change (A BIG deal
> > when
>
> I am pretty sure KConfig does that itself.

no, it doesn't. using KConfigXT with your UI means that when the user can't 
set something because of a Kiosk setting in the KDEDIRS chain those elements 
get disabled automagically. this is already a reported issue, and was even 
commented on by a user at dot.kde.org. in other words, this is a visible 
issue.

as for not storing default settings, how does KConfig know about default 
settings exactly? there is a lot of config dialog code in KDE that simply 
stores whatever values were set w/out checking to see if they were the 
default settings.

> And I remember the last time you 
> did something like that with toolbars --- it tooks months to get them in
> vaguely working order, and for many people, including myself, one also had
> to do surgery on config files to recover.

the KConfigXT code is already tested and works =)

> > -MUCH Easier to add/remove options to kde applications.
>
> Questionnable, 

my experience with KConfigXT says he's exactly right. i'm sure there are 
situations we could find where this isn't the case, but i think it's a 
generally correct statement.

> and some of the apps don't have maintainers. Who is gonna 
> add the options?

you can't tell me with a straight face that with every release many KDE apps 
get new features and in turn new controls in their config dialogs? you are 
right that not every application gets new configurable features, but many do. 
those apps would stand to benefit.

> > -Faster startup (due to), less memory usage, and shorter compile times in
> > many cases (due to removal of junk code).
>
> Do you have any numbers to back this up, in particular on the first 2
> points? If you don't, you're just making stuff up.

speed and memory consumption is secondary in this case to the code reduction, 
IMHO, as that translates to more maintainable apps. given that we have apps 
without maintainers, this becomes ever more important.

but there are other benefits such as the XML files that result that open up 
the possibility to perform searches on settings that previously just were not 
possible (think search in kcontrol) and how it allows usage of KConfigEditor 
across a broader set of applications...

straight porting of configuration dialogs is not that hard nor that risky in 
the majority of situations. it's relatively simple "here's the widgets, 
here's the XML file, go at it" code.

of course, i don't think it should become a *requirement* for application 
maintainers to port their stuff to KConfigXT or ELSE! this should be, as with 
any other work, work done voluntarily by those with the motivation in concert 
and cooperation with the maintainers. kind of like everything else we do.

KConfigXT has benefits over "doing it by hand", and if there are people 
willing to do this work then i don't see why we would want to get in their 
way. all new development incurs risk, yes. but we manage that risk fairly 
well, and i don't see this as a high risk enterprise.

now, if KConfigXT porters start going nuts and changing config file key names 
and other unecessary stuff then we'd start having issues... so... we just 
need to be reasonable in the porting: change as little as necessary to make 
it KConfigXT ready....

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43