why kdelibs?

[Stephen Kelly]

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

I didn't get a "Qt is all you need" vibe at DevDays, but the Qt developers 
there are completely unaware that the kde libraries are available and 
usable. Most still think that KDE is a monolithic desktop environment, and 
set of applications. Nothing independently useful or usable.

So awareness is one issue, and one which I'm trying to address. Another is 
interdependence in kde libraries, and what I think of as upside-down-ness in 
parts of the stack and modules. kdelibs is mixture of two things: a set of 
libraries, and a platform. KJob is in the libraries conceptually, as is 
KIMAP, whereas KStandardAction, which someone mentioned, KStandardDirs, 
KSyCoCa, KGlobal etc are platformy because 1) They provide benefit to well 
integrated KDE applications, and 2) They provide no benefit to Qt developers 
who are not creating 'KDE integrated' applications. Qt developers often have 
control over distribution of their own dependencies and can be more specific 
in code about data directories etc than KDE applications.

Because of interdependence though, a developer who wants to use KIMAP must 
also use KStandardDirs, KComponentData, KGlobal and everything else they 
come with. It should be possible to use a an IMAP library without depending 
on the entire 'integration platform', so I think of kdelibs as upside-down.

Even if communication about the separate KDE Development Platform had 
reached the Qt developers at DevDays, I don't know if they would care, 
because they would want libraries, not a 'platform' with all the buy-in 
baggage that entails.

The result for the Joe the plumbers^W^W^W Gregory Schlomoffs of this world 
is privately managed ifdefs and hacked target_link_libraries lines.

http://dot.kde.org/2010/10/15/gregory-schlomoff-betterinbox-kde-development-
platform

Thinking of the kde libraries in terms of how people like Gregory and other 
software vendors which create and deploy (and self-manage the deployment, 
paths, dependencies etc) could see and use them could be a good way to make 
kdelibs more modular and independently and make the 'platform integration 
pieces' appear much higher in the stack.

Anyway, making a list of (mostly-)independent libraries which are 
potentially interesting to a Qt developer is easy:

KLocale: More powerful i18n than QObject::tr and friends. Based on gettext.
KConfig: More powerful settings management than QSettings.
KJob:    Asynchronous APIs for executing tasks. Includes progress reporting.
Kross:   Cross-language script interpretation
Threadweaver: Threading APIs to suit practical needs of applications.
KDEUI/ItemViews: Add-ons to the Qt itemviews API.
KMime :  Qt based library for handling emails
KIMAP :  Qt based library for asynchronous IMAP communication

I've only included things which I have some familiarity with. The list could 
be made longer of course.

All of those could be useful to 'Qt applications', and they only depend on 
Qt for the most part, or other libraries in the list (KIMAP depends on KMIME 
and KJob, but Qt has no equivalents for those). Conceptually there's no 
reason for them to depend on 'the platform'. 

The fact that they can't be used independently out of the box makes 
communicating about them difficult. "If you're using Qt ItemViews for 
serious business, you want to use the stuff in kdeui/itemviews, but it 
depends on klocale, kconfig, kfile etc etc at shipping time, none of which 
are used." Actually kconfig is used in one place, but that's removable.

Hopefully there's some coherence in all that. I had intended this email to 
be much shorter.

All the best,

Steve.