February 17, 2019

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

Most Popular LinuxPlanet Stories