Slashdot Mirror
Interview: Ask the KDE Developers
Gnome has gotten the lion's share of Linux desktop publicity lately. Meanwhile, KDE has been quietly working on KDE2.0, which will hopefully contain several interesting features including a WWW browser called Konqueror and the long-anticipated KOffice, a free office suite that may provide a viable GPL *nix alternative to StarOffice and Applixware. Rather than speculating, we've decided to ask the people who are actually doing the work what they're up to. Post your questions below. Tuesday we'll send 10 - 15 of the highest-moderated ones to selected KDE developers. Answers will appear Friday.
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? I need nothing less than 100% support for at least Excel and Word file formats. It would also help if the support was entirely transparent - no kuldgy 'export' or 'import' required.
Also, an Exchange mail client would be REALLY nice.
-josh
In light of this, where do you see the desktop in, say, 5 or 10 years time?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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?
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?
Still not dead.
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?
In Soviet Russia, hot grits put YOU down THEIR pants.
As a current OS/2 user who is experimenting with Linux, and as someone who knows many former OS/2 users who have switched to Linux, I'm curious as to whether the KDE development team is at all aware of the Workplace Shell, OS/2's object-oriented desktop. It seems as though the KDE and GNOME projects are concentrating on making Linux familiar to Windows users by emulating Windows's UI... which is nice and all, but you can only go so far by emulating the Windows UI, and after you get that far you'll have the same problems that Windows 9X and NT have.
I've read many posts on Slashdot and (and other places) that lament the abandonment of the Workplace Shell by IBM, and even former OS/2 users lament the lack of any similar Object Oriented UI in the Linux world. So then, my question is "are KDE developers familiar with the Workplace Shell, and are there any plans to incorporate similar features and technologies into KDE itself?"
Eviscerati.Org: All Hail the Eviscerati
First, let me start off by saying that I think this is a really nice idea. Now off to my qestions.
/usr? I personally like it in /opt. Anyhow, this created a lot of problems for me (and I'm sure it did for lots of programmers), because I tried to install several applications for KDE from RPM, but because they were older (i.e., for Red Hat 5.x) they installed into /opt. Is there going to be some kind of rule or way that such things will be prevented in the future?
1. In the 1.x series of KDE, we have seen some nice interaction between the programs and the actual system. However, all that was required was that a program be written in QT, and also maybe use the KDE libraries. My point is that there was not a lot of system interaction and integrity which can be observed in other systems. For example, databases and such didn't exactly have to be standard, KSCD uses its own, and other CD players use THEIR own. Anyhow, will we see a much tighter environment with KDE 2.0, besides what we already know?
2. There was a big problem with what Red Hat did to KDE in it's 6.0 release. Putting it in
3. Will the next KDE be able to read menus from other WMs? Such as E, GNOME, FVWM, etc? I think it is nice that we see such things in other WMs such as GNOME, and it sure would help in organizing user menus. Also, the menu editor in KDE 1.x has been cryptic and difficult. Since there isn't much information on the new system, will it be easyer, more like a tree (yes, Windows-style) of shortcuts or something similar?
4. In the past KDE was not able to interact with applications from other desktop environments very well. For example, if I have X-Chat or Grip (grip is for making MP3s) installed, they won't gain a lot of recognition in KDE because the are gnome apps, same goes for XMMS. Will KDE in the future be able to detect some of these applictions (and will the limit of XPM icons be removed?
That's all! Thanks!
yeah
You may not read or even like him, but John C. Dvorak had an interesting article on the future of the desktop called "The Future is DOOMed" (Oct 19, 1999). His point was basically that the idea of putting folders within folders within folders is flawed and illogical. He then tried to speculate what a new model would look like, even bringing in the idea of "3d" file management.
My questions are these: What are your ideas for a "desktop of the future"? Do you agree with Dvorak that the current model is ridiculous and needs to be rethought? If so, what will that look like? (3d??)
-------
"Every artist is a cannibal, every poet is a thief."
It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?
What comes to mind are:
It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.
If you're not part of the solution, you're part of the precipitate.
Will there be language bindings for developers who would rather use other languages when developing KDE apps?
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...?
What I'm listening to now on Pandora...
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?
I believe that one of the MAJOR problems facing *any* UNIX system wishing to compete on the desktop front is application level support for a printing subsystem as well as low 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...
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
Here are seven distinct question areas that follow from that:
- Is this supposed to be simply a free rewrite of what is essentially existing Windows functionality, or is there something in it for the rest of us? If so, what kind of thing can we get excited about? What sort of consideration has been taken to accommodate the long-time, professional Unix user? What kind of compatibility is there for existing Unix programs and formats, and for the entire Unix mindset? Will we have to learn completely new editors, mailers, newsreaders, web browsers, and pagers, or are there hooks that respect the Unix users existing preferences in these areas? Does it feel like an integrated part of Unix, or something stuck on the side and completely apart? Is the default look and feel something that Unix users will find repulsive just because it reminds them too much of Microsoft? Do you use Windows widgets by default?
- What support will there be for the handicapped and disabled? Will there be keyboard interfaces, or only mouse-based ones? Both the visually-impaired and the RSI-agonizing benefit greatly from having the option of employing a non-mouse, textual interface. Will there be keyboard-based, tab-style completion features? What about fully programmable completion at the toolkit and/or application level? Is there a way to do a quick text search through all menus so we don't have to do the same thing repeatedly? For example, the entire toolkit and window manager could conspire to let META-/ followed by a regexp take you directly to the currently focussed program's particular menu that contained that pattern no many how many mouse clicks deep it was in nested menus, and META-n could take you to the next match, META-N the previous one, etc.
- Is there any scripting mechanism planned, preferably with a language-neutral API so that we can use bash, perl, guile, tcl, python, javascript, or even some BASIC-style language? Is there going to be anything like Microsoft's ActiveScripting stuff? How about anything analogous to Gtk/Perl?
- 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.
- What usability tests have you run? Were your subjects only Windows users, or did you try non-computer users as well? What about usability tests that involved professional, long-time Unix programmers?
- In what ways do you see Gnome feeding ideas back into KDE, or vice versa? Is there anything from Gnome you've specifically rejected, or specifically incorporated? Same thing with Enlightenment.
- What is the state of the documentation? Is it externally accessible, searchable, typesettable, and printable? Does each command have complete documentation of its calling interface, whether CLI or otherwise, and is this documentation externally accessible, or most you tediously step through help buttons in the program itself? What about configuration matters? Are they completely documented, or are you forced to read existing examples for a clue? Finally, what about the library functions that programmers will be using? Does each function have its own complete documentation, such as the fine work you see in glibc? Or are you forced to read existing programs to guess how things work instead of having a formal specification and description? Is all this documentation integrated into one place, or must you hunt all over for it?
Well, that's enough for now.