Redefining kdelibs and kdebase

[Maks Orlovich]

On Sunday 28 August 2005 06:21, Christoph Cullmann wrote:
> On Sunday 28 August 2005 11:50, Christoph Cullmann wrote:
> > Hi,
> > guess what we really want is this scheme I describe in the .png file.
> > We want the current KDE framework for KDE apps and a interface allowing
> > ISV's to integrate their apps slightly.
>
> I guess I need to add some thoughts to make the picture move obvious ;)
> (had to left for Dirk's talk, therefor the quick short mail ;)
>
> a) What we should aim for kdelibs for KDE 4
>   - clean up the API (slightly)
>   - reshape that we have some core/ui seperation like QT has now
>   - improve kio,kconfig,... whatever
>   - make it eaiser to port over kdelibs to other platforms while not
> loosing our functionality

Note that one part of this sort of cleanup is important for point (b): if we 
let KIconLoader be usable from style plugins, we can use the KDE icon theme 
for some standard items defined in Qt (not sure whether it risks a mis-match, 
though)

>
> b) What we should provide for ISV's:
>   We should create some linking independent interface lib which allows
> ISV's to use the KDE specific features on unix and have fallbacks for
> windows/mac and the gtk+ unix case. This interface floats on top of the
> kdelibs/gtk+/win/mac API and provides some long term stable interfaces for
> example you would need to use some "mailto" dialog in any ISV app without
> linking to any specific toolkit.

An another alternative is of course to make it easier for pure-Qt apps to get 
KDE functionality w/o much effort, so those targetting primarily Windows and 
OS X could get decent KDE integration, too. e.g. I remember someone on pk.o 
blogged about a framework that lets one transparently use KIO from apps using 
Qt's network transparency class. 

<snip view on modules, which I disagree with, but don't want to discuss atm).

-Maks