why kdelibs?

[Kevin Ottens]

Hello,

Took this mail as a reply as Stephen wrote most of what I had in mind already. 
Thanks you dear Steve for this prompt use of your KMindReadingProxyModel. :-)

On Friday 29 October 2010 07:08:35 Stephen Kelly 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.

Well, and even if they claimed such a thing it's definitely a fallacy which 
would need to be pointed out...

> Most still think that KDE is a monolithic desktop environment, and
> set of applications. Nothing independently useful or usable.

... and to be debunked. If such a fallacy still spreads that's mostly because 
of this false perception.

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

+1 with all of that and the rest of your writing on the matter. From the work 
I'm doing now I reached the conclusion, we definitely have a form of 
schizophrenia in kde*libs which we'll need to solve at some point. Solving it 
will actually make our libraries an order of magnitude more desirable to third 
parties.

It's definitely something close to impossible to properly solve in a BC way at 
that point unfortunately. I'd love everyone to remember that thread and that 
particular mail once we start tinkering about a KDE Whatever 5.

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

Note though that there's likely two things to keep in mind:

a) We have to be careful to not split our libraries too much, if they become 
too small and too numerous we'll very likely pay it in application/workspace 
startup time on some platforms (definitely need to be carefully benchmarked 
and so on, there's a trade-off to find).

b) Some of those "platformy" features you point out, we'll have to evaluate 
which one could/should be in Qt itself API wise (the KDE Platform then 
providing backends for it). For instance, nowadays what's the point API wise 
between KIcon("foo") vs QIcon::fromTheme("foo")? They both got very close 
lately... KStandardAction that you mention, why is it not handled by Qt 
directly? Just like it already does with QKeySequence::StandardKey.

If the open governance model for Qt ever comes true, there's opportunity for 
us to rollback some of this platformy features in Qt (API wise). I'm sure the 
pure-Qt MS Windows developers out there would love to have standard actions 
which play well in this platform, up to us to make it play well in our 
workspaces as well.

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

At the light of my points above, assuming open governance of Qt running at 
full steam:
 
> KLocale: More powerful i18n than QObject::tr and friends. Based on gettext.

Why not push its features in Qt itself?

> KConfig: More powerful settings management than QSettings.

Why not improve QSettings to have it on par with KConfig?

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

It's definitely much longer. And right now we're not that bad anyway, most of 
the features from kdelibs are in neatly separated libraries these days. Where 
we fail though? Mostly: kdecore, kdeui and kio which could be much more fine 
grained. That totally made sense for historical reasons (actually still make 
sense), but we'll really have to think about them in a different way for the 
next major release (as we both proposed just now in our respective emails).

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

And most of the time its Qt job to abstract "the platform". I know Thiago is 
already in this mood, and I approached him on that matter already, but I think 
he's right that at some point the KDE Platform should be just another platform 
supported by Qt.

I'd love to see a time where we'll provide a KDE Platform neatly abstracted 
away by Qt, and a KDE Libraries Collection which are add-on modules to Qt. 
Most of what is in kdesupport these days qualify: QCA, etc., it's time kdelibs 
gets cleaned up to reach a similar state.

Now, to ever see that happen, we'd really need the open governance really in 
place (right now everybody knows how painful it is to get anything in Qt), and 
the trolls helping us helping them to get the niceties of some of kdelibs 
platformy features.

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

Sounds very coherent to me, but that's maybe because I'm burying myself in a 
lot of structural patches for kdelibs these days... So hopefully I didn't 
break your coherence. I likely failed though. ;-)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101029/d91b953d/attachment.sig>