KDE4 Libs components

[David Faure]

On Friday 03 March 2006 23:11, Olivier Goffart wrote:
> If later we want to modify a class to make it depends of another, we can't 
> anymore.
This is a problem with every library structure, not just the proposed one.
Like currently, you can't use a kio class from kdecore, unless you can actually
move the kio class up to kdecore (like was done for ksycoca), but that's not always
possible.

> (this may happen if we add a global configuration key that change the 
> behaviour of a class in the 'components' library.

This is a good example though. KDirWatch would have been a good candidate
for KDEFoundationCore, except that it has two kconfig keys (polling interval).
(Note: there's no way kconfig can belong to foundation; it's for sure part of
"framework" since it depends on kstandarddirs, i.e. the kde directory-structure framework)

So either we have to remove that configurability from kdirwatch, or we need
to turn it into an API call - which would be very annoying since every user app 
would have to set those values -, or we need a KDirWatchBase/KDirWatch split 
so that kde apps use the high-level version which reads the config, or we need
to use QSettings for that particular bit of config (huh...). Neither is particularly
appealing though.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).