post 3.3 kconfig_xt work
Aaron J. Seigo
aseigo at kde.org
Fri Aug 13 04:03:51 BST 2004
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
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
> 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.
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
More information about the kde-core-devel