.comment: KDE3 Is Coming - page 2

Building KDE and Qt 3

October 10, 2001

By
Dennis E. Powell

I didn't spend a world of time in the new desktop both due to a
lack of time and the fact that there is a whole lot that I didn't
like. The KDE splash screen has been replaced with a new one that
doesn't quite work correctly -- the blinking icons are missing -- and
about half the time the KDE desktop itself didn't start, though Kicker
fired up and it was usable. On the occasions that the desktop did
start, the background programs did not work, even the ones such as
XPlanet that should work no matter what version of KDE is running, in
that they're not KDE apps. Due, I suppose, to the new QT, Opera would
no longer work, and Opera is one of those applications without which I
cannot do. I do not know if Mosfet's wonderful liquid theme works with
the KDE3 alpha; if I'd decided to stick with the alpha I would have
tried to compile it against the new libraries to see if it does; it is
also something I have come to require. (I do wish that the KDE folks
and Mosfet could make peace so that this theme could be included in
the standard distribution, along with Pixie, which I also very much
miss.)

One of the most important of the new features isn't a KDE feature
at all but a QT one: qtconfig. This is a nice GUI configurator that
creates a ~/.qt directory that contains a single configuration
file. One must use this utility to enable typeface anti-aliasing as
well as the checkbox in the KDE Control Panel. (Even so, I never got
anti-aliasing to work in the KDE3 alpha, which further precludes its
permanent placement on my desktop.) The functioning of the
applications in the alpha was spotty at best -- editing messages in
KMail, for instance, is just awful, because the text handling isn't
quite right. Many of the applications seemed to be straight ports,
meaning that when they worked they were little different from their
KDE-2.x counterparts. I saw no evidence of threading of applications,
but I'm glad that the KDE people recommend configuring QT to use
threads anyway, because this will prove a considerable boon to
third-party application developers. The KMenu has resprouted that bar
along its side that serves as a little KDE advertisement. I presume
that it can be turned off; I have always thought it was a waste of
space and code.

The alpha is slow. On an Athlon 1.2 with 764 megs of memory, it
was considerably slower than KDE-2.2.1 is on a K6-2-550 with 256
megs.

Now. Please do not think for even a second that the above is any
criticism of either the alpha or of those putting it together, because
it isn't. It's not just an alpha, it's the very first alpha, and the
fact that it built uneventfully is itself a remarkable
accomplishment. Instead, my observations are merely to let you know
before you go out and build it that it has not yet achieved a level of
working new stuff to justify tolerating the stuff that's broken. It's
important -- very important -- for us mere users to grab early
versions and actually use them, day in and day out, for we then
provide that many more eyes and that many more test machines. My point
is that the KDE3 alpha isn't yet where that's likely to be a useful
exercise.

The feature freeze was, last I heard, scheduled for November 2. By
then there is likely to be an alpha that's far enough along that
stouthearted users could migrate more or less permanently and
contribute worthwhile bug reports.

In the Meantime

I've been giving more and more thought to a topic that was touched
on here a couple of weeks ago, when I quoted an email message posted
to the kde-devel list.

It has to do with some of the things that would help Linux be
taken seriously in the enterprise. If this is not a goal that you find
worthwhile, come back next week when I'll be taking about something
else, because what follows will be of interest only to those who do
think it's something worth seeking.

There are a few things that distributions could easily do to help
Linux get taken seriously, most of which are evident when one
discovers that they haven't been done. For instance, I have a Red Hat
beta running on the lab rat machine. It defaults to use of Jamie
Zawinski's magnificant XScreensaver -- as it should; no problem
there. What is a problem is that it includes the "Phosphor"
module, which echoes to the screen various sayings in a fashion that
resembles the old green, slow-recovery monochrome monitors; this
itself isn't troublesome, but the provided sayings most assuredly
are. I remember glancing up and seeing "You will be dead in a
year." Nice. Really nice. Some of the other sayings are equally
clever.

Point is, a distribution that wants to be taken seriously by
businesses has no business shipping that sort of crap.

I digress a little, though, from the main point, and that is the
issue of backward compatibility. KDE3 uses a new QT, which is
incompatible with QT-2.x or anything earlier. Earlier applications,
such as Opera, won't work anymore, or if they do it will be because
they were statically linked or else have a whole other set of
libraries aboard -- either of which kills system efficiency. We can't
very well complain of the bloating of other systems when users could
very reasonably have favorite old applications that don't make the
jump any other way.

Yes, Troll Tech is to be criticized for paying best I can tell
absolutely no attention to backward compatibility. But before the
fever swamp erupts with "see -- we said that tying a desktop to a
commercial library would come to no good," let me note that this
is a systemic problem throughout Linux. It is by no means limited to
QT. It's all over the place. Chasing Linux libraries is an enjoyable
pastime if and only if your chief purpose in running Linux is building
stuff rather than using it. To everyone else, it's a royal pain in the
ass. Our library directories are filled with twice as much stuff as we
need, and we're using twice as much memory as we ought to require,
simply because no one pays attention to people who might have some
affection for a legacy application. The KDE folks are doing a whole
lot of work porting everything to the new QT, but there are a lot of
third-party applications for KDE -- good, completed applications that
do the job for which they were intended. Some of these will never be
ported, because the developers are disinclined to fiddle with them
just because the libraries have changed out from under them. The
theory is that if it's a sufficiently important application, someone
will grab the source and hack it over. This theory is pretty much
nonsense -- there are orphan applications all over the place.

KDE2 was a great enough improvement over KDE-1.x that people
wisely upgraded. It remains to be seen, and I've seen little evidence
of it (but it's early days yet), whether KDE3 will be an equivalent
improvement, worth replacing QT-2.x and the apps that need it, or
worth kludging together some way of making them co-exist at, again, a
high price in system resources. In any case, once again the libraries
will need to be upgraded if KDE3 is to be used. (I suspect that the
chief improvements will be not so much in KDE itself but in KOffice,
which is fast approaching must-have status, the lone prohibition being
the lack of good filters, such as the ones I'm told are found in the
new Star/Open Office beta.)

This is no big deal for hobbyists. The only cost is time, of which
there is plenty. But for businesses, to whom time is money, this is
just as expensive as are Microsoft's upgrade scams. What's more,
applications are often not with a particular version of their
libraries long enough to fully exploit them. Application developers
are in a perpetual state of catch-up.

To be a successful platform for businesses, and especially
business desktops, we need to find a solution to the problem of
library creep. The best solution would be to try to keep our APIs
intact, so as to maintain backward compatibility. The situation is
now, as it has been, way too confused.