why kdelibs?

[John Layt]

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 
need.

Off the top of my head, some of the good stuff:
* Proper localization of Calendar Systems, i.e. your app will play nicer in 
foreign countries
* 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 
instance:
* 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 
unique?

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 
different e-mail...

John.