johnlayt at googlemail.com
Thu Oct 28 16:47:59 BST 2010
On Thursday 28 October 2010 12:11:43 Chani wrote:
> When I was at DevDays, I noticed that while people were very enthusiastic
> about Qt, I was getting a sort of "qt is all you need" vibe at times - a
> fine sentiment for promoting qt, but then, what about kdelibs?
> And then I realized: what *about* kdelibs? I had no idea how to tell anyone
> why they should use the kde platform, what advantages it would bring. Hell,
> at this point I'm not even sure what's *in* kdelibs, or what the KDE
> Platform is.
> After a quick skim of community.kde.org, I'm just as lost.
> So I ask you: Why kdelibs? Why the KDE Platform? I *know* that we have all
> kinds of awesome in there, but what is it and why should people use it?
In general, we provide lots of convenience classes and methods for things that
are either awkward to do in Qt, or you have to do yourself. The concept of
being an add-on module to Qt providing stuff to make Qt coding easier is
valid, but then we also have lots of stuff designed for integration into our
platform, like consistency between apps and localization that others may not
Off the top of my head, some of the good stuff:
* Proper localization of Calendar Systems, i.e. your app will play nicer in
* Far more date formatting options than Qt has
* Proper timezone handling
* World's best File Dialog.
* Extra features added to the print dialog on *nix that Qt seems to have no
interest in supporting
* Unit Conversion library, e.g. km <-> miles
* KIO network transparent file operations
* All that Semantic stuff
* GUI widgets that integrate all this good stuff so you don't have to
* A holidays library that no other platform has an equivalent for
However with Qt moving from being just a widget and container toolkit to be an
entire development platform, i.e. implementing all the api's the mobile
platform needs, we're more often running into the problem of duplication. For
* KHTML/KJS vs QtWebKit
* Phonon vs QtMultimedia
* Solid vs QtMobility
* Akonadi & kdepimlibs vs QtMobility
Where in the past kdelibs users could happily use our stuff as an add-on and
not think much about it, now they have to make decisions as to which
incompatible module they will use and accept possible limits as to how well
they will integrate on each platform. Some KDE apps already have Qt only
versions that restrict how well the KDE version integrates into KDE or force
them to re-implement kdelibs stuff. How long before such apps decide the KDE
side isn't worth the hassle, that a compatible widget style and a few shared
dialogs is good enough?
What do we need to be doing to make sure that using kdelibs is not seen as
being a disadvantage, that it is worth the extra weight for all the goodies?
Or is chasing the non-KDE market just not worth it if we loose what makes us
Big questions. Anyone with big answers? :-)
I'm thinking about this stuff as I'm trying to plan for GeoLocation support in
kdelibs. Do we stay in-house and copy bits of Marble into kdelibs, but then
cut out the mobile guys who will want to use QtMobility. Or do we use
QtMobility and the problems that entails away from the mobile platform? Or do
we write some Phonon-like wrapper that will use whichever is installed, but
that's no better for the mobile guys than any other new API? But that's a
More information about the kde-core-devel