why kdelibs?

Alexander Neundorf neundorf at kde.org
Sun Oct 31 20:34:07 GMT 2010

On Sunday 31 October 2010, Juan Carlos Torres wrote:
> On Sun, Oct 31, 2010 at 1:50 AM, Cornelius Schumacher 
<schumacher at kde.org>wrote:
> > KDE would still create great applications based on Qt, just as we do now,
> > but
> > without the additional layering of the KDE libraries on top of Qt.
>  <snip>
> > KDE is much more than the libraries, actually if KDE would be about
> > libraries
> > already now nobody would be interested anymore. KDE is community, and a
> > community creating great software for end-users. We have tons of
> > applications
> > people love to use, and a community who loves to create them. How many
> > libraries they use, and how the stack is layered doesn't really matter,
> > does
> > it? For technical details, yes, but there actually maintaining our
> > platform as
> > integral part of Qt seems advantageous to having a separate layer, which
> > is hard to sell, sometimes hard to use, and very hard to maintain.
> >
> > The KDE community would still do the same as now, the differentiating
> > factor
> > would still be creating great software for end-users. If Qt would have
> > provided everything we needed we wouldn't have created kdelibs. Assuming
> > the
> > obstacles we have seen and still see in actively being part of Qt can be
> > removed, we wouldn't have a strong need for our own special platform,
> > would we?
> So basically, what would convince 3rd party developers
> (Qt developers, Windows developers, iOS/Android developers)
> to write KDE apps? Better yet, what would now constitute being
> a "KDE app"? Platform integration and consistency? 

Probably the use of KDE services like KStandardDirs, the KDE mime system, 
kparts, nepomuk, maybe kioslaves, plasma.

Software which only uses some libraries developped by KDE could be 
called "powered by KDE libraries" or something like this.

Our promo guys have clearer definitions for that I think.

> Only on
> desktops/netbooks perhaps. On mobile, we'd have to follow
> *their* (Maemo, MeeGo, WM) platform. Why not just call the app
> a Qt app then? Again, this is from an interested 3rd party
> developer POV. Established KDE SC apps would most
> probably keep the same brand.
> True that KDE is much more than the libraries. But aren't those
> libraries also an important part of what makes KDE? I mean, if
> developers decided to make KDE apps, isn't it sometimes
> because KDE libraries rock?

We have different types of libraries, and it would be even cooler if those 
libraries which don't have KDE-internal dependencies could spread even more.
E.g. KLed ;-)
Other examples from current and past include arts, phonon, kjs, strigi, 
akonadi, and more.
They all are/have been often perceived as libraries which can only be used if 
you write a full blown KDE application, while they are actually independent 
from the rest of KDE, I think arts was also independent from Qt.


More information about the kde-core-devel mailing list