kconfig and kde global config files

John Tapsell johnflux at gmail.com
Sat Mar 4 03:44:57 GMT 2006


Couldn't kconfig just watch the kdeglobals files for changes and reread then?

On 3/4/06, Aaron J. Seigo <aseigo at kde.org> wrote:
> hi all...
>
> reworking kconfig i noticed that with each and every kconfig object we parse
> all the global kconfig files. it seems than an easy optimization would be to
> only parse the non-local-to-user global config files once per-app by caching
> the results in a static mapping in KConfig.
>
> this would mean some additional memory usage (we'd have one extra copy of
> the
> system-wide global file mappings) but we'd save on parsing those files and,
> more importantly probably, stat'ing all the KDEDIRS for config/kdeglobals
> and
> config/system.kdeglobals.
>
> however, this would mean that to see the results of  updated values in
> kdeglobals one would have to restart applications. since changes to system
> wide config files are relatively rare and many kconfig objects are
> long-lived
> (and others short lived) in apps it occurred to me that this is probably not
> a horrendous thing.
>
> i have done 0 benchmarking and am simply relying on the "common sense" that
> moving metal == slow. so, usual caveats about my common sense, yadda yadda
> ;)
>
> additionally, i noticed that we look for -both- kdeglobals and
> system.kdeglobals. i was completely unaware of system.kdeglobals. where does
> that come from? and do we need BOTH kdeglobals and system.kdeglobals? should
> we keep them in kde4 just for backwards compatibility (at the cost of some
> more stat'ing about on disk)?
>
> --
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
>
>




More information about the kde-core-devel mailing list