Dependencies (KTrader / kdeui)

[David Faure]

I wanted to move the koFind and koReplace classes from koffice to kdelibs/kdeui
since Shaheed made them generic enough to be of use in any application
(for proof, I was able to use koFind in kbugbuster to look for a string in listview
items, and it's used in both kword and kspread).

At the same time, I looked at replacing the current regexp-related popupmenu 
by the full KRegExpEditor. However this requires KTrader to locate the component
and KParts::ComponentFactory to create it. Those two things are in kio and kparts, 
which kdeui doesn't link to.

This brings the question whether we shouldn't move kservice, kservicetype, their ksycoca
factories, kuserprofile and ktrader to kdecore - the rest of the ksycoca classes are already
there. Those things are quite basic, and useful complements to klibrary/klibfactory: they
are necessary to locate the right library to dlopen.
KMimeType would have to remain in kio, it needs KRun. That's where the limit is,
KMimeType is file-related, whereas kservice and kservicetype are generic notions.

Conceptually, the point in kdecore/kdeui was to build the UI over the core things,
we're now in the situation where core stuff is in kio, so we can't build UI classes
using them.

As to KParts::ComponentFactory, it's all in the header file, as templates, so 
it can actually be used from kdeui, IIRC. But... shouldn't the non-KParts-related
method of it move too? If KTrader is in kdecore, I think they will be able to.
We'd use another namespace (or even classname), and leave "forwarders" in 
kparts/componentfactory.h for source compat.

-- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today