netterfield at astro.utoronto.ca
Wed Nov 3 05:51:12 GMT 2010
On Thu, Oct 28, 2010 at 1:11 PM, Chani <chanika at gmail.com> wrote:
> 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?
Some perspective from a non-core-devel app developer:
We've been asking ourselves this very question for kst (kst.kde.org) a
program for plotting real-time data and for time stream analysis.
*** History ***
I started kst around KDE 1.96. The team size has gone up and down as
various experiments picked up the program. We moved it into extragear
sometime in 2.x, where it continued happily through KDE 3.5.x. The
2.x to 3.x transition was painless and quick.
We started to port to 4 around the first KDE 4 alphas. We decided to
initially port to Qt4 only, delaying any decision regarding KDE4 to a
later time. As anyone who has done a KDE 3 to 4 port knows, this job
was huge, and we are just now reaching approximate feature parity with
the KDE 3.x version (some large areas missing, but there are some very
>From a developer's point of view, I like the new code base much more,
but a lot of the benefit here is related to our own cleaning up the
code, rather than intrinsic benefits of Qt4 over KDE3/Qt3.
>From a user's point of view, the last couple of years of work we have
put into kst for this port are nearly irrelevant, except that we now
run on Windows.
BUT: we are not in KDE4 extragear (yet) since we don't pass the
techbase requirements (mainly failed krazychecks, which can really
build up in 120k lines of code. But we are grinding the list down
step by tedious step, because they are good suggestions.)
AND, as I've said, we don't use kdelibs.
*** Why (or why not) kde? ***
Why would we now start using kdelibs?
1) The resources the KDE community provides - translators,
2) The resources kdelibs provide: eg, standard dirs, kio, i18n,
date/time stuff, KDE desktop integration.
(1) is more important than (2)
Why would we NOT use KDE?
Some of my users use OsX and Win, so I 'need' convenient tri-platform
(I'm assuming from rumors that) it is still less convenient for our
users to install KDE on windows than to use Qt4 alone, and that
KDE4 under windows is a bit... awkward. Please correct me if I am wrong!
(Note: from my point of view, using kdelibs in its current form *under
linux* would not provide me with any undue pain and suffering,
and would be a clear net positive.)
*** Analysis (my 2 cents) ***
(some already has been said, but I'm putting my weight behind it...)
Merging KDE4 into QT4 (in-and-of itself) doesn't fix problems we have
or would have if we used kdelibs (though making it so you could do the
It could help to split kdelibs up to a finer level, so we could take
the relevant (and portable) parts, and not use stuff we don't need or
that doesn't fit well in the Windows or OSX paradigms. Then, we could
start kst without starting KDE services that kst doesn't need.
Even better: as well as splitting things up, take the source API for
the 'desktop specific' stuff and re-implement it under Windows and Mac
to provide the desired functions in a desktop appropriate way. eg, I
would love to have a good 'kstandarddirs' capability under windows!
*** In any case, a violation of source code compatibility more
significant that the KDE2 to KDE3 changes would probably kill kst. We
have barely recovered from the KDE 3 to Qt4 change. ***
C. Barth Netterfield
University of Toronto
More information about the kde-core-devel