RFC: kservice -> kdecore?
faure at kde.org
Wed May 17 23:46:26 BST 2006
On Thursday 18 May 2006 00:25, Aaron J. Seigo wrote:
> for kconfig having multiple backends, it makes the most sense to allow people
> to provide backends as plugins. the "natural" way of doing this is to query
> ksycoca for KService's that match, for instance, "KConfigBackend" as their
Yes. It would be good if the default backend wasn't loaded as plugin though,
for speed, but also since KTrader initialization uses kconfig to load the user preferences....
> b) move the essential KService stuff into kdecore alongside KSycoca*
> option 'a' is pretty unappealing. unfortunately, option 'b' ends up winding
> down a long dependency chain. it really gets nasty when KService makes it's
> one and only call into KServiceTypeFactory with:
> t = KServiceTypeFactory::self()->findPropertyTypeByName(_name);
So? You need to move KServiceType too anyway. When you said "KConfigBackend"
above that was a service type.
> KServiceTypeFactory relies on KMimeType
That's where we could break the chain, by having a separate KMimeTypeFactory
to create KMimeTypes.
> KService::List KService::allServices()
> return KServiceFactory::self()->allServices();
> deprecating these static functions in KService and requiring the use of
> KServiceFactory means no dependency on KServiceFactory.
Wrong. You need a KServiceFactory to create your KServices from ksycoca
in the first place.
This idea matches the idea I had, I was planning to
to kdecore, since we will also need it for spell-checking backends.
(My idea was to move KMimeType too, I even started some cleanups for that
like the deprecating of QPixmap methods and the separation of KDEDesktopMimeType,
but maybe we can avoid moving kmimetype until the need arises).
I'll have a look at separating out KMimeTypeFactory tomorrow if you want.
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel