steveire at gmail.com
Fri Oct 29 06:08:35 BST 2010
> 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.
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,
More information about the kde-core-devel