[414] in Athena User Interface
KDE findings to date
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Sep 12 00:45:59 2000
Date: Tue, 12 Sep 2000 00:45:54 -0400
Message-Id: <200009120445.AAA07170@egyptian-gods.MIT.EDU>
From: Greg Hudson <ghudson@MIT.EDU>
To: aui@MIT.EDU
Here is the dirt I have dug up on KDE so far, based on the KDE 2.0
beta 4 release ("Kooldown"):
* I had several problems compiling the code, even under Linux.
The configuration system used in kde packages does not try
to obey general autoconf tenets; it overwrites the CFLAGS
value from the environment, and won't find the qt library if
you set CPPFLAGS and LDFLAGS appropriately; you have to use
KDE-specific options. Qt itself is a mess of
nonconformancy; its "clean" target removes the Makefiles
generated by "configure", it has no "install" target and
instead expects you to build the source code in the
destination area, it won't build static and dynamic
libraries at the same time, its handling of user-specified
compile and link options is highly inconsistent, etc. etc.
Also, annoyingly, KDE has recently started naming one of its
subdirectories "core", which isn't very nice to people who
import their releases into CVS repositories. The KDE people
didn't seem very amenable to changing this.
I haven't had any luck getting things to compile on Solaris
or IRIX. The problems have ranged from automake bogosity
affecting IRIX (although that was partly my fault) to
obscure C++ compile errors I couldn't decipher.
On the plus side, once you get past the support libraries
(libpng etc.) and Qt, the KDE build system is very
homogeneous. They use a single set of (poorly written)
autoconf macros for all packages. Gnome seems to have more
required components with unique build system abnormalities.
* KDE people aren't the best at handling bug reports. When I
submitted a bug report (with stack trace) about a program
dumping core on startup, it was closed without any kind of
response being sent. The developer who closed it later said
he figured it must be a bug in my installation, since the
program worked for him. It turned out to be a libpng
problem (was fixed by upgrading to libpng 1.0.8), but I had
to find this out by myself.
* Whenever you start a nontrivial application like kconqueror
(the file/document browser) or koshell (the office suite),
it has to fire up four programs in the background. These
background programs don't go away when you terminate the
application. That's pretty annoying when you're trying to
run KDE programs standalone.
* I haven't been able to get kconquerer or koshell to find
support for any basic services (like "how to view a
directory" or "how to handle a URL"), so I haven't managed
to get them to do anything interesting. As far as I can
tell, I built and installed everything per the instructions,
so this suggests something brittle in their code.
* The KDE library code I have looked at is exceedingly
convoluted, making it prohibitively difficult to debug the
aforementioned problem.
* The KDE games seem to run okay, but I later noticed that the
several games I had tried out had dumped a total of 10MB of
crud into my homedir (image files and stuff, presumably
copied out of their shared data area). Not cool.
We've had frustrations similar to these with Gnome, but I thought
people (particularly Bill) should know that all our problems wouldn't
be immediately solved if we were using KDE. (Also, I haven't reported
any frustrations which I would have run into if I hadn't already
learned things from the aui locker. For instance, I think the
timestamps perl script helped immensely.)
