why kdelibs?

[Gregory Schlomoff]

On Fri, Oct 29, 2010 at 12:08 PM, Stephen Kelly <steveire at gmail.com> wrote:
> 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.
>
>
>
>

Hehehe, I was planning to jump into this thread and share a few ideas,
but now that Stephen drew me in, I almost have to :)

So, my story is: I'm not a KDE user, but I'm a Qt application
developper, and I found *very* useful things in kdelibs. KIMAP is now
a central part of our app, we are using KJobs everywhere we can, and
we are contibuting back with KSmtp, a job-based SMTP library (more on
that in a future announcement).

But, as kdelibs / kdepimlibs are now, I see 2 main problems:

1. Out of the box, the build process is monolithic and involves
building a ton of things with a huge amount of dependencies. I haven't
counted, but there are probably 5-10 million SLOC to build.

2. Many modules assume that they can find settings / configuration in
certain places, or they are providing their own dialog / UI elements
to report errors and information, and this is a very bad thing when
you're not using the dektop environment side of KDE.

Point #2 is the more problematic, because it simply makes it
impossible (instead of just hard) to use some libraries.

In order for a library to be usable by Qt developpers, it must take
all it's input from the program using the library, and it must return
all it's output to the program. There must be no side-effects, no
dialogs, no reading of configuration files, etc... And this is not the
case today, because several libraries assume that they are going to be
used in the full KDE desktop environment.

So, my feeling is that right now KDE is a closed ecosystem : it
provides you with everything you need to make KDE apps on the KDE
desktop. This is great, but it's easy to understand why it's not very
appealing to Qt-only developers.

What can we do ?

1. Identify, as Stephen did, independent libraries that are useful to
Qt developers
2. Split kdelibs into a part that comprises only those libraries, and
a part that answers the problems specific to the desktop environment
3. Maybe have a clear branding, with different names

Thanks for this highly interesting discussion,

Greg