Redefining kdelibs and kdebase
mo85 at cornell.edu
Sun Aug 28 16:54:12 BST 2005
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,
> 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).
More information about the kde-core-devel