RFC: kservice -> kdecore?

[David Faure]

On Thursday 18 May 2006 00:25, Aaron J. Seigo wrote:
> hi....
> 
> 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 
> type.

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

> 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 
KService+KServiceFactory+KServiceType+KServiceTypeFactory+KTrader
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).