From kde-core-devel Thu Oct 28 15:47:59 2010 From: John Layt Date: Thu, 28 Oct 2010 15:47:59 +0000 To: kde-core-devel Subject: Re: why kdelibs? Message-Id: <201010281648.00123.johnlayt () googlemail ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=128828093222413 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.