KMimeType in kdecore

[David Faure]

Next monday, after I commit the splitup between KDEDesktopMimeType and KDesktopFileActions
(new namespace for what's currently in the static methods in KDEDesktopMimeType), I'll be ready 
to move KMimeType to kdecore.

More precisely I'll be moving 
 kmimetype.cpp kmimetype.h kmimetypefactory.cpp kmimetypefactory.h kmimemagicrule.cpp  kmimemagicrule.h
 kmimetypetrader.cpp kmimetypetrader.h kdedesktopmimetype.cpp kdedesktopmimetype.h
to kdecore/services (or kdecore/mime?), and kmimetypetest to kdecore/tests.
And the installed tools ktradertest and kmimetypefinder should move to kdebase/runtime, I realize now.

This will
1) ensure that no GUI code creeps back into those classes again :)
2) make it possible to find mimetype from non-gui code, e.g. ktradertest and 
kmimetypefinder won't have to link kdeui+kio anymore.
3) make it possible to share the d pointer between KServiceType and KMimeType
and make it possible to un-export some code that is shared by KServiceTypeTrader
and KMimeTypeTrader (e.g. applyConstraints(), or KServiceType::m_mapProps), now 
that they'll be in the same library.

Any objections?

Ah, there's still one problem to solve: the messagebox "No mime types installed" from KMimeType.
I could use a kWarning instead, but it won't tell end users that there is really a big installation problem
(no shared-mime-info or more likely no ksycoca file). We could move the check to kapplication;
it won't cover all cases (now that kapplication is optional), but that might be good enough still.

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