Stephan Kulow wrote:
> 
> Hi!
> 
> I have on my hard disc a quite big change in the way
> KConfig works in KDE. Nothing of what Preston touched,
> but how it looks for files. It follows now the
> many-reads-one-write concept KStandardDirs introduced
> more transparently.
> 
> So you only give it the filename in a relative path
> and kconfig looks itself where it's present. When it
> writes, it just writes to .kde/share/config. Either
> into appnamerc or into kdeglobals. I also removed the
> file creation code in KApplication as it was rather
> pointless to write in KApplication no matter if KConfig
> will write something or not. It's KConfigBackEnds's
> job to create the files if needed.
> 
> I will need some time to test it, but I want to apologize
> right now as I'm sure I'll break something :)
> 
OK, I did that now and I also added some debug output
to parse and writeConfigFile while I was at it. And if you
now look at for example the start of kcmdisplay, you'll
see a _lot_ of parsing going on. I don't think, that my
changes have caused that, but there are many wrong or
suboptimal uses of KConfig in especially the control
modules.

KConfig has two optional paramaters: 1. readonly and 
2. useKDErc. especially the 2. is very interesting if
you want to read for example kwmrc in kcmkwm or in
any kio or kfm related stuff. 
Think about it, that the KConfig constructor parses
about 5 files and looks for about 15 :)
Of course this is open for optimization in KConfig,
but it's much harder to do there as to add a false
in the right places.

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online