Slashdot Mirror
Interview: KDE Developers Answer Your Questions
Before we get down to business, we'd like to stress that these are the opinions of individual KDE developers. The answers below are not *necessarily* the same as the KDE Official Position on matters. If you wish to know THE official opinion on any of these, contact the KDE Core Team through any of the official representatives.
Now that's out of the way, so here we go:
1) by joshv
One of the biggest limiting factors that stops me from moving to Linux
for 100% of my computer use is the poor support for MSOffice file formats in
Linux Office apps.
What level of support will KOffice provide for MSOffice file formats?
Kurt Granroth answers:
The level of support is entirely dictated by how much support the
filter authors are willing to do. I can guarantee that we won't have
100% compliance with Office97 formats if only because it's not
possible to get the complete specs for all the formats. My personal
feeling is that we will have support for the most common parts of
Word97, Excel97, and Powerpoint97 for KOffice 1.0 (or soon after) but
the more esoteric features will be lacking.
As I said, though, it's entirely up to those who are actually writing the filters. If somebody (or several somebodies) jump into filter writing fulltime, then it's entirely possible that we will have the best filters in the Unix world. We'll have to see what happens...
2) by jd
There are a number of competing environments in X, now, such as KDE and
Gnome. In addition to that, there are emerging whole new windowing systems, such
as Berlin. Add a sprinkling of GGI, KGI and EvStack for good measure, and you've
a real gloopy mixture of ideas and strategies.
In light of this, where do you see the desktop in, say, 5 or 10 years time?
Richard Moore answers:
I think the X environments will become much more interoperable as
standards are defined for functionality such as .desktop files,
drag and drop and the capabilities of modern window managers. The
standards around at the time the KDE project started (such as the
ICCM standard) do not define these service. Now that there are
some real standards being defined (and implemented) such as XDND
and the new window manager specification the diversity of X can
be made a strength rather than a weakness.
Developments such as Berlin and GGI are interesting, but they are not really much of a concern to KDE. As these projects become more mature it may be worth porting our code, but for now this is not a priority. One of the advantages of writing highly object oriented code (and using a cross-platform framework such as Qt) is that it is very easy to port, and should the need arise this would not be problem. However as X is improving anyway, especially with the current developments in XFree86 such as GLX support (hardware accelerated 3d) the arguments for a new windowing system are not very strong.
Over the next few years I expect to see evolutionary, rather than revolutionary changes to the desktop. As usual there will be lots of new ideas around, but only some of them will stand the test of time. I think there is likely to be much more emphasis on the 'look' of the desktop, and on improving the ways data is presented. Some trends such as greater use of multimedia, more 3d, more use of transparency are likely to continue, but it is hard to say what else will be around.
Kurt Granroth answers:
Personally? I don't think it will be significantly different. I know
that there is a tempation to say that in 5 years, the desktop
metaphor that we currently use will be dead and we'll have some
radical new approach. Well, I don't believe it. "Normal" people
really aren't very willing to change what they are comfortable with..
and they are now comfortable with the desktop approach. Any changes
that happen will have to happen gradually over a period of time.
Now whatever happens, I'm sure KDE will roll with the change. With only a few exceptions, our API is pretty well abstracted from the graphics layer. Say the next big thing is an OpenGL 3-D graphics background (is that what Berlin is?) -- all KDE needs to do is convert a few parts of the base Qt library and we'd be good to go on the new backend.
3) by Jon Trowbridge
What are your thoughts on both the current status and the future of
interoperability between KDE and Gnome in areas like components, CORBA, etc.
Do you see the two projects moving closer together, moving further apart, or staying about the same?
Richard Moore answers:
There are some areas where cooperation between KDE and Gnome is
possible, and others where it is more trouble than it is worth.
There has already been good progress to produce standards for
.desktop files and window manager hints. The functionality needed
for these is well understood making them relatively easy to
standardise from a technical point of view. It is less obvious
how more complex technologies such as component embedding and
reuse can be defined in a usable standard. That said however
several KDE apps have been ported to Gnome and when we release
KOffice, KDE 2.0 etc. I imagine they will want to try to embed
our components - if they can get it to work they are welcome
to. I don't really see the projects moving closer together
though as we have very different ideas about how the desktop
should work.
Kurt Granroth answers:
Please see my answer to question #7.
4) by Zarniwoop
What do you plan to support in Konqueror, ie CSS, Java, HTML type, and
will it function as a file manager or will KFM still have that function?
Richard Moore answers:
Konqueror is using Lars Knoll's new DOM based HTML component - it already
supports almost all of HTML 4.0. Support for Javascript is progressing,
though the DOM bindings are unfinished as is support for CSS, both of
these are under active development and will probably be ready for KDE 2.0
(though not for the Krash release). Java support is partially complete -
most simple applets now work, but there is currently no support for applets
in JAR or ZIP files. In addition it is now possible to create plugins for
Konqueror that can further extend its functionality - in future there
may even be a bridge that allows the use of Netscape plugins!
In addition to being a web browser, Konqueror can do a lot more - it is able to embed different types of view using the new KParts framework (briefly known as Canossa). This means that it is possible to view any type of content (eg. text files, postscript, DVI files etc.) within Konqueror. The views are loaded and unloaded as needed which keeps the browser itself nice and lightweight. A view doesn't just embed the content - it also has access to the menu and status bars, drag and drop etc.
The file management component is embedded in Konqueror, so to a user it works in much the same as with the old KFM did, only better. The file view has been completely rewritten and now provides a much more polished user interface, for example you can have multiple views and you can load and save workspace layouts. As before the files are accessed using kioslaves allowing you to transparently access both local and remote files. The ioslave code has been rewritten to improve performance and to make it easy to add new protocols. There are a number of new protocols already implemented (such as SMB a.k.a. MS Windows shares) and also extensions to the existing protocols (such as SSL support).
Kurt Granroth answers:
Konqueror is a generic browser -- it has the capability to browse
almost any medium that it has a component for. That is, with our
treeview and iconview (and similar) parts, we can use Konqueror as a
file manager. With the helpcenter component, we can browse help files
(html, man, and info). With the kghostview component, we can "browse"
postscript and PDF files.
And with the html part, we can browse the web. This component is clearly the one that gets the most attention -- and deservedly so! We (mostly Lars Knoll, though) are working on an HTML library that is fully HTML 4.0 compliant. It is already pretty darn close. We use DOM Level 1 as our document model and should have some parts of Level 2 in by KDE 2.0. We will surely have support for CSS1 and *maybe* support for parts of CSS2. We already have minimal support for Java applets and Javascript.. and the capabilities of both will increase by KDE 2.0. In the case of Javascript, we should be able to handle 90% of the most common pages on the web.
Hmm.. I think we'll have some support for parsing xhtml and embedded XML, also.
Konqueror is essentially the next generation KFM, BTW. It does everything KFM could do.. and tons more! Furthermore, it does it much faster and using much less memory.
5) by Kris Warkentin
I've heard that KDE 2.0 will be using a new window manager KWin rather
than KWM. Now I know that KWM is a big fat hog but I haven't been able to find
much info about KWin. What are the advantages to this new window manager? Is it
an evolution from KWM or a completely new, from the ground up program?
Kurt Granroth answers:
KWin is a new, from the ground up, program. It is written to be more
modular and extendible and to have theming and MDI capability built-in
(kind of.. see below). It is also a tiny bit better with memory.
The 'theming', BTW, is pretty cool because, technically, KWin doesn't do theming at all! KWin is really just a window manager library that you can build a window manager on top of. When you write a 'theme' for it, you are (in ways) really creating your own window manager with that particular look. This means that you aren't limited at *all* to the inherent theming capabilities of the wm if you are willing to do a little programming. And I do mean "a little" programming -- the BeOS example style is less than 200 lines of very easy to understand code.
However, I take exception to calling kwm a "big fat hog". If you use kwm with KDE, then it is no more memory intensive then any other modern window manager. In my experience, kwm is as fast and light as any other full-featured window manager out there.
6) by Otter
When designing KDE, what is the minimal hardware quality you expect it to
run comfortably on? Is it currently available low-end, one year old low-end,
three year old low-end...?
Kurt Granroth answers:
Well, whenever I recommend computer systems these days, I always
insist on at least 64M memory, a 6G hard drive, and a 366Mhz system.
That said, we made sure that KDE will run on significantly less then
that :-)
The consensus seems to be that 32M is the minimum that you could comfortably use. You could use less.. but then you'd have trouble with just bare X, much less KDE. Hard drive size and processor speed shouldn't be a major factor at all. Video cards shouldn't play a significant role, either. We now ship high color (24-bit) icons.. but we won't drop the 8-bit icons until we're sure that all 8-bit cards are gone.
Keep in mind that the above recommendations are for the x86 platform. You may need to adjust the numbers when referring to, say, SPARC or Alpha chips.
7) by TheGreek
Has the long-standing flamewar between KDE and GNOME helped to motivate
development of a better product, or has it just made you annoyed at the community at large?
Richard Moore answers:
No.
Kurt Granroth answers:
(This is also my answer to question #3)
It may suprise some people, but most KDE developers don't wake up every morning thinking about GNOME -- I know that *I* don't! In fact, I very rarely think of them at all. I spend my time thinking of, and working on KDE.
Do I think that the KDE and GNOME "war" has motivated a better product? No! I think the whole "competition makes for better products" thing is bunk. KDE developers work to make KDE the best that they can -- and they would be doing so even if GNOME didn't exist! KDE would be exactly where it is right now regardless of the status of GNOME.
Has the "war" made me annoyed at "the community"? At times in the past, I did get annoyed at those participating in the flamewars. I think it's incorrect to say that they are "the community", though. The fact that KDE has an overwhelming majority of Linux desktops shows that "the community" (if there is one) has been behind KDE all along. Those flaming KDE are easily dismissed.
Now all that said, I'm a big supporter of working together with GNOME to standardize as much low level things as possible. Let's face it, there are some nice apps coming out of the GNOME/Gtk camp and it would be a shame if they couldn't be easily integrated into the KDE desktop. I want to be able to use, say, xchat, gvim, or gimp and have them look, feel, and act as much as possible like my other KDE apps.
This means that what needs to be standardized is things like drag 'n drop, window manager "hints", file associations, menu structure, key bindings, themes, and the like. Work is already done or in progress on the first three listed and the last bunch look promising. On the themes note, I seriously doubt that we will have 100% compatibility between GNOME and KDE themes.. but we should get pretty close by having theme
8) by twdorris
I believe that one of the MAJOR problems facing *any* UNIX system wishing
to compete on the desktop fr level printer driver support. It's been a while
since I've coded X-apps, but from what I recall, there was no way to "cleanly"
handle print functionality. By that I mean, I always ended up with one routine to
draw to the screen and a completely separate routine to write my PostScript
output for printing. I believe this may still be the case give how many different
print interfaces I see in various applications running under Linux. No two user
interfaces are the same and no two produce similar results. To an end user (at
least at the desktop level), this is extremely frustrating and it's one of the
main reasons I *have* to keep Windows around. I need to print things reliably and
with a high degree of quality and there's just no clean, easy way to do that
under Linux or any other UNIX OS for that matter.
As for device driver support, I've used Ghostscript extensively in the past and while it's impressive, it's a FAR, FAR cry from being comparable to a vendor-supplied, Windoze-based driver equivalent with regard to quality of output and reliable printing. As an example, try printing a high resolution image to an Epson Photo 700 under Windows and then do the same under Linux using Ghostscript. The two are completely different and it's not in favor of Ghostscript.
All this leads me to my question for you guys. I use KDE along with KWM as my working environment at home. How do you see printing functionality being affected or enhanced by KDE and do you have any suggestions for how to improve upon the current state of things? Is there a huge re-write of printing support under *nix systems that I don't know about and that most applications these days are being coded to? I strongly suspect so, because there's no way in hell Linux will be able to compete in the desktop market if every application is required to write out postscript data manually and/or include printer drivers for every printer known to man. Both Windows and Java take an approach to printer support that ties printing code to display code and I believe something similar is *really* needed under Linux and/or X11. Do you guys have a feel for what the future holds with regards to printer support under *nix systems? Having coded a complete office package yourselves, I'm sure you have a pretty good idea... :-)
Kurt Granroth answers:
There are a number of parts to the printing problem... and only a few
can be solved at the KDE level. We actually have a very nice
printing mechanism in KDE using the Qt library to do all the real
work. If you've done any Windows programming, you'd see that it is
*similar* to the way that MFC handles printing. Basically, we 'draw'
onto objects with QPrinter and QPainter.. and really don't care if the
final output medium is paper or a screen. All of that work is handled
at the Qt level.
Specifically, Qt will render it up into postscript if the code is intended for paper (e.g, a printer). It then uses whatever printer drivers are available to do the actual printing.
This is where the differences between printing in Windows and printing in Linux start shining through. You are correct that on most low-end printers (i.e., non-laser), the output in Windows is *much* nicer. This is out of the control of KDE, however. The drivers need to work at the OS level.. and it's there that they need to get a lot better.
I believe that there is some work to get vendors to ship official drivers for Linux. If/when that happens, then all output from KDE apps will immediately see the improvement. The actual code in the apps won't have to change at all.
09) by Ledge Kindred
I don't follow KDE development extremely closely, but it seemed to me
that details about Magellan popped into
sight very suddenly and vanished again nearly as quickly. Considering the power
and capabilities detailed in the article linked above, this sounds like a major
component to having a devastatingly powerful desktop based on KDE2, since an
easy-to-use EMail client like Magellan would fulfill one of the two basic "killer
apps" I imagine an average user would want from a desktop environment. (The other
being a decent web browser, which KDE2 looks to also provide with Konqueror.) Is
development of Magellan still on track? Can we reasonably expect it to live up to
expectations? Or is this considered an "out provide and therefore outside of what
you can comment on?
Kurt Granroth answers:
Magellan isn't part of the KDE project... but we're glad to see it
coming along. Third-party apps like Magellan, QCad, KDevelop, and
KDEStudio are very valuable even if they aren't provided with the KDE
core packages.
Now personal opinion time on Magellan: the screen shots look *very* nice and if it has all the functionality it claims.. well, I think there will be a lot of ex-Outlook users that will be very happy. That said, I've never actually seen it working or seen one line of code from it. The author certainly has the right to keep it all hidden before release.. but until it is, it's just vaporware with very pretty screenshots.
10) by Tom Christiansen
What non-Windows systems have you evaluated in mining existing
technology for ideas? How about XEROX Star or OS/2 or Amigas? Have you ever
looked at AVS, the scientific visualization graphical shell? It has (or had, when
I long ago looked at it) a very cool graphical representation in which datasets
and filters get connected in by pipelines in a visual rather than a CLI way,
which is sometimes easier to produce. IF you haven't seen it, think of what it
might be to combine drag-and-drop with connect-the-dots...
Kurt Granroth answers:
The systems we mine are those that we've used. So you can see
elements of Windows, MacOS, NeXT, and traditional Unix desktops like
CDE. We do try to emphasize the visual elements from Windows and
MacOS because, let's face it, that's where the newbies are coming from
and we want to make sure that they have a comfortable, intuitive
environment to work in. It should be possible for an ex-Windows or
ex-Mac user to sit down in front of a KDE workstation and figure out
how to use it very quickly and with little or no help. It's possible
that there are some OS/2 inspired elements in KDE, too.. but I don't
think I'd recognize them if they were there (I haven't used OS/2 in
years).
As for the 'connect-the-dots' approach.. I believe that various KDE apps are doing something in that vein. aRts does (or did). I could have sworn that there were more. We currently have no plans of doing this in the core KDE stuff.. but who knows what will happen after KDE 2.0
Actually, it's interesting that you mention AVS because we *did* have a rather extensive discussion about treating everything as graphical pipes about a year ago (I think). If my memory holds true, we decided that it's a great idea but we probably couldn't pull it off by KDE 2.0 if we wanted it to be stable, usable, and intuitive. Like I said, we'll see what happens after 2.0
Over the next few years I expect to see evolutionary, rather than revolutionary changes to the desktop. As usual there will be lots of new ideas around, but only some of them will stand the test of time. I think there is likely to be much more emphasis on the 'look' of the desktop, and on improving the ways data is presented. Some trends such as greater use of multimedia, more 3d, more use of transparency are likely to continue, but it is hard to say what else will be around.
Translation: 'We're making it look better, because we already think it works as well as it could. The Windows paradigm is good enough, no sense coming up with new ideas.'
This kind of attitude is deeply worrying. No, the desktop metaphor is not perfect, in fact it has many flaws and weaknesses. (Check out About Face: The Essentials of user interface design by Alan Cooper for hints.) Something new needs to come along! KDE (and GNOME) are just rehashes of Windows 95, the same way CDE was a rehash of Windows 3.1. Do we really want for free software to be chasing the coattails of the lowest common denominator? I think we can do better.
It's not just Unix users that are affected by this limited vision, but they are the ones most likely to be familiar with the pipes-and-filters methods that MS WIndows-like desktops are simply incapible of utilizing. So they're more keenly aware of What's Missing.
The fact is, the emerging free-software desktops might look better than MS Windows, be more configurable than MS Windows, and work better than MS Windows, but they don't break any new ground. Drag'n'drop gives no more functionality than the DOS 1.0 command line: feed filename A to application B. Component models make programming easier, but in themselves do nothing to improve desktop functionality. The fact that it is impossible to use the desktop to order a seqeunce of operations on one or more objects--something that should be absolutely basic--shows just how limited the desktop metaphor remains.
I'm sure some folks will say "just use a CLI," and that's certainly what I'd do. But there are natural ways to make a GUI do the same sort of thing, such as what Tom suggested in his question--from drag'n'drop to connect-the-dots. And this would just be the beginning of using hugely intuitive visual metaphors to allow everybody to do the things that only ksh/bash gurus can do now.
It's just a crying shame that the KDE folks are relegating themselves to improving the same tired and limited conceptual framework that MS Windows inhabits.
Free software has craftsmen a-plenty, and good ones. But where are the visionaries?
- The File/Edit/Goto/Bookmarks/Options menu bar doesn't make any sense. To make a new help window, you have to go to File. What does that have to do with a file? Likewise to search. I mean, honestly -- what are you thinking? This is a general problem in all the KDE stuff I looked at. You keep putting things in really non-intuitive categories. I mean, get serious: you've got "System", "Settings", and "KDE Control Center". Those make no sense to me. Why are some programs in one of those categories, but not another? What's the difference? "Applications", "Utilities", and "Internet". How am I supposed to look one place and not another? What's the difference between a program that's an "application" and a "utility"? And what about "Graphics", "Multimedia", and "Internet". Why aren't the graphical programs under Multimedia? Why is local user information (finger config) listed under "Internet"? Don't tell me "oh, you can edit those". The defaults should be sensible. These aren't.
- There's a "search" under File, but then a "find" under Edit. Why is there even an Edit button? How can I edit anything in static documents?
- Also under the File menu is some "Close" command. But when I used it, it didn't close the file I was viewing, which is what you expect a "File/Close" command to do. The other meaning of close, iconify, was actually what I was expecting. But guess what, the KDEhelp wasn't iconified. It was completely destroyed without warning or confirmation! You should choose a better word there. People who use the word "close" to mean iconify will keep killing things. On the other hand, "Destroy" (or perhaps better, "Exit") and "Iconify" aren't ambiguous.
- The next line, the one with happy icons on it, is not intuitive. How do you disable the pictures and turn on just the words, the way you can in netscape?
- It appears that you use the same happy icon in the KDEhelp window to indicate "reload current document" as you use in another menu to "rearrange icons". What the devil is this overloading about? This cryptohieroglyphic system doesn't help anyone at all. What does that bitmap mean? Why does it mean something totally different elsewhere? Why aren't there words?
- You can't use the regular keyboard for paging activity. I tried everything I knew. I used SPACE, BACKSPACE, ^F, ^D, ^B, ^U, B, F, b, f, ^J. Nothing works. This is not intuitive. How do I make it follow the conventions of less(1)? Even netscape recognizes space and backspace for going back and forth by a screenfull. This is what I mean about discriminating against people who can actually touch type.
- The cut-and-paste system doesn't by default work like xterm. How do I change that setting? The reason I need to do this is because your defaults are very week, but less powerful than I'm use to. It doesn't seem to follow the model of index-finger clicking once for a character, twice for a word, and thrice for a line. Even netscape can do this. Why can't you? And once you've grabbed a word (for example) you can't use the ring-finger click to delineate the word at the other end.
- In KDEhelp, you make the user guess whether something is, whether it's in man, kde, or info format. How is the user supposed to know? That's not nice.
- The presentation of available man stuff is just nowhere near reasonable. For example, choose section 1. You get a zillion names of commands. 964 of them, in fact. I can't visually search a thousand different things like that.
- You don't provide the whatis description of each man entry in that listing. That means the user has no way to guess what the page is about. That information is important.
- When it comes to choosing a section, you ignore both the users MANPATH setting and the operating system's default. That means you can't find, for example, ssh which is in
/usr/local/man. settings from the /etc/man.config file. (Actually, that file's name and syntax varies depending on your operating system, even within the family of operating system. Redhat Linux puts it under name, SuSE Linux puts it another name, and Debian Linux puts it in a different name still. And these actually have different parses, too. E2MANYLINUCES. Sheesh. But they're not alone. FreeBSD has its own notion of where to put the config file and how it parses, and this is different OpenBSD's notion of the same. And please don't talk to me about Solaris.) But the point remains that you have to respect the local configuration, or else you aren't actually doing what you say you are. - The output format is alphabetized on the X axis instead of on the Y axis the way it should be for convenient reading. People want to read down columns, not across rows. Why? Because it's a lot faster. If you keep going across the rows, you have to do a carriage return with your eye constantly. It's all back and forth and back and forth and back and forth. But going down the columns, you don't have to do that.
- So, your program doesn't understand man trees, whether in MANPATH or in the system config file. This is a problem, because you can't tell which mantree the hits came from. Also, you aren't able to limit you search to just locally installed stuff versus the standard operating system, etc.
- On the "Keyword Search", on the other hand, it does seem to respect your local conventions. It's also quite fast. I'll bet that's because it's just running apropos directly, which is more clever by half.
- The "Keyword Search" takes forever (ok, a very long time) when specify KDE documentation. Once again, you make people know where things should be.
- The documentation search, when you specify manpages, doesn't distinguish between the whatis database and the raw data. How do I say which one I mean?
- You do not provide a "word boundary only" search option. You don't tell people whether they can use a pattern match, but even if they can, would that be a \ or \bword\b?
- The return list is not helpful. It is not sorted in any understandable fashion. It does not show any of the line or sentence that matched. It contains redundancies. For example, one set of returns looked like this: But those are not really to the same places. They just have the same title. It looks like they did a full body search, but I can't tell.
- When you follow one of those links and return via the left arrow (hey, how does that play in right-to-left reading places?), it runs the whole damn slow search again! This is nutty. The KDEhelp window should cache those results. And why does it do a manual search anyway? Why don't you have a quickly searchable text corpus database index that's pre-generated by the system?
- When you hit the left-arrow to return to your search, you have lost the string that you were searching for. It's gone from that window. In fact, so are the button settings.
- I sometimes managed to get the Search window in some state where I couldn't just hit ENTER to launch the search, but had to use the silly mouse to push a button. I didn't figure out how to reproduce that consistently.
- In the Search window, you're sitting there typing something, and you hit ^W to back up a word (those are in my stty settings). Guess what? IT DESTROYS THE WHOLE WINDOW! Did you hear what I just said!? You don't get asked permission. It just destroys it. You lose all your state, your forward-back list, and your sunny and pleasant disposition. This is completely evil.
- I've tried to mouse grab from the KDEhelp window and paste it into the Find window. But I can't do that. It seems to have its own separate buffer system. This is very confusing.
- There's no "Clear" on the Find window to help with cut and paste.
- When you want to do a search, you have to hit ^F. How do I make that be a slash instead?
- When the find window pops up, it doesn't have the focus. Instead, you have to searching for it with the mouse. That's a waste.
- You can't use your normal editing characters in that little box it gives you. I tried ^U (my kill character), but was ignored. I tried ^W (my werase character), but was also ignored.
- If you already have a "Find" window up, but it's exposed, you don't realize this. You sit there in the KDEhelp window hitting ^F again and again, but absolutely nothing happens. There's no new find window that appears, no beeping, no flashing, and no raising of the existing window that you don't even know is open.
- The Find window is named "kdehelp". That's what shows up in the title bar and in the icon manager. That's not a good name, because it's not really the kdehelp window. It's a transient Find window managed by KDEhelp. Why is it even showing up there in the icon manager?
- When a Find fails, it pops up a "Find Complete" confirmation window. And this one is also without the focus, so you have to go chase it down with the mouse. That's crazy. You have nothing else to do. It should have the focus. You can try scrolling the KDE help window on your own, but it completely ignores you. It refused to do anything until you take your mouse and attack the Find Complete window. With a vengeance.
Consider this a bug report. The operating system is Red Hat Linux release 6.0 (Hedwig) , standard installation. I couldn't figure out how to report KDE's version: But it was the standard Redhat OS from VA, so you should be able to guess.While we're at it, what is that X11 stuff doing in /usr/bin? You aren't supposed to do that, you know. Otherwise you make non-X11 people suffer the search costs that they don't need. Help, /usr/bin has more than 1400 entries in it on this Redhat OS from VA. Somebody wasn't thinking: Linux is notoriously bad with large directories. Please don't contribute to this problem.