why kdelibs?

[Juan Carlos Torres]

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? 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?


-- 
Regards,

Juan Carlos Torres
Jucato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101101/ab242e57/attachment.htm>