post 3.3 kconfig_xt work

[Benjamin Meyer]

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

On Thursday 12 August 2004 11:03 pm, Aaron J. Seigo wrote:
> 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.

The code is in the KConfigXT configure dialog code and not KConfig so for all 
those apps just like you say they save everything.  Applications can add this 
into there own code if they wish as the backend functionality has been added 
to KConfig.

[snip]
> > > -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.

Looking through my backup cd's I wasn't able to easily find my ktron stats, 
but feel free to checkout kde 3.0's ktron and today's ktron.

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

I 100% agree.  Reducing the amount of code means there are less places for 
bugs, less to maintain and less to learn when new developers work on the 
project for the first time.  And by using a common system the configure 
dialog look/feel/behave the same across KDE which is a major user interface 
win for KDE.  <gnome jab>Consistency is key, not 
simplification/reduction.</gnome jab>  

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

And other info like knowing that the int has a range of 30-50 and the ability 
for descriptions

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

Which was why I initially suggested it as a JJ task.  Help them through one or 
two apps and then they could help with other apps while exposing themselves 
to a lot of KDE and they feel like they are actually usefull.

> of course, i don't think it should become a *requirement* for application
> maintainers to port their stuff to KConfigXT or ELSE!

Agreed.  Some apps work better without kconfigXT and some can't use it at all 
(kdm?)  But for the majority of middle of the road applications it is win 
win.  I didn't mean to start a flame war listing every app that MUST be 
ported or anything, just listing apps that didn't use it that could be ported 
(i.e. to make a big JJ list).  In the past I have always (I hope) e-mailed 
the author of the app before making the change sense although not that hard 
it does touch a lot of the application code.

> now, if KConfigXT porters start going nuts and changing config file key
> names and other unecessary stuff then we'd start having issues...

kconf_scripts for the most part have been usefull in solving the naming 
changes (see the kicker clock thread from a year or so ago for fun reading).

- -Benjamin Meyer

P.S.

> so... we 
> just need to be reasonable in the porting: change as little as necessary to
> make it KConfigXT ready....
Along those lines some of the apps I listed haven't even been ported to xmlui 
yet... along with other KDE features.  When porting apps to KConfigXT I have 
ported a number of apps to XMLUI, converted to use KMainWindow features and a 
lot of other little cleanups that has been in KDE for while.  These are also 
excellent JJ jobs.

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

iD8DBQFBHDeO1rZ3LTw38vIRAlUAAKCyoud+jT6J0rlQ9xuW1c1IhQy/YACaAo9z
0LLIJwNRsAs/nan/6/2cLsw=
=vpAd
-----END PGP SIGNATURE-----