Redefining kdelibs and kdebase

Christoph Cullmann cullmann at
Sun Aug 28 17:01:01 BST 2005

On Sunday 28 August 2005 17:54, Maks Orlovich wrote:
> 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)
For sure ;) And if we have for example some polished kdecore/kdeui which are 
based on pure QtCore/Gui it might attrack some people to use parts of this in 
their QT apps, too, as many widgets are even without the kde framework 

> > 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.
yeah, but for cases where such transparent magic doesn't work, the interface 
lib could provide hooks to help ISV's get that stuff done in a long-term BC 
way and without the hassle to do it on their own for the different platforms.
But most important: As this interface lib is a layer above the 
KDE/GTK+/Win/Mac platform it won't harm nor speed down our kde devel process 
even if this stuff needs long term API stability or some lowest-common 

> <snip view on modules, which I disagree with, but don't want to discuss
> atm).
yeah, guess there are many views about the actual way to split the kde stuff 
in pieces or let it like it is, guess that is more implementation detai we 
need a thread on it's own ;)

More information about the kde-core-devel mailing list