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
My question:
How far do you think the GUI can go from here? What's next in GUI design, and what'll be the next big thing after pointy-clicky?
dylan_-
--
Igor Presnyakov stole my hat
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 do you think will be the most important legacy from the KDE project? A desktop environment? A framework for applications? KOffice? A bunch of little applications that make life easier (kppp comes to mind)?
--
QDMerge 0.4!
how to invest, a novice's guide
As a user of KDE, one of the first things that I have noticed is that by default, the close button is next to the maximize button. Because KDE is configurable, I put the close button on the left and left maximize on the right.
Although one goal of KDE is to have the user interface immediately familiar to Windows users, what is the project going to do to correct Windows user interface problems, such as putting the close button next to the maximize button? (The problem here is that users will often accidentally press close instead of maximize and vica versa. There are many other examples in Windows, such as the confusing start menu: KDE's is better, etc. Copying the Mac is not the best thing either ex. "Use the Chooser to connect to the network AND select printers." etc.)
Henry Lafleur
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.
One of my biggest complaints with StarOffice (outside of the licensing issues) is that StarOffice is one large binary with many different office features. This requires you to load the entire binary into memory (a time wasting process) to utilize a single feature of the StarOffice suite. In light of Linux's appeal of being able to run on a box made up of spare parts found in one's closet, this seems counter to the mission of Linux. Granted, new machines are coming standard with at least 96 MB RAM (typically more), but I still have an old P150 with 32MB that I use from time to time... so, my question is:
Will KOffice treat each of the applications as separate binary executables, or follow the one-large-binary approach of StarOffice?
Eric
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.
There is KDE and there is Gnome. Competition here is a good then, and both are equally welcome. There are, however, many concerns about software incompatibilites of Gnome apps vs. KDE apps, and that there is a fracturing of inter-program communication standards, since Gnome and KDE apparently handle this differently and may be incompatilble.
Some time back, there were some noises made about the KDE developers and the Gnome developers coming together and finding some common ground that would allow both environments to get (somewhat) get along together.
Has there been any talk between the two camps about standards development and such?
jf
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
I've used both desktops off and on for the past couple years and I've seen both good and bad features about both desktops. I have no plans to embrace one desktop over the other, so my question will focus on the two interacting.
I don't frequent mailing lists of either camp, but I've heard bits over time such as perhaps a common desktop-entry format. That's nice, but I'm far more interested in, essentially, cooperation whenever possible and practical. This is, IMHO, in keeping with the Linux spirit by allowing more choices. From an end user standpoint, the DnD should be compatible, desktops' respective productivity suites/applications should always be able import/export each other's format, web bookmarks ought to be accessible from both sides, and so on. So my question would be, what sort of plans and/or discussions are going on to facilitate compatibility, rather than forcing users to use either one desktop or the other?
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
Will the features from the corel filemanager be part of kde2, in that case, will it be corels code or another implementation?
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?
When I first came across Gnome and Kde, I was very confused about why there are 2 seemingly similar "free" efforts, why a lot of the linux community supports Gnome (since it is not based on QT), why instead of everyone getting behind one project and making sure we roll out something formidable together, there were 2 fragmented efforts. However, do you think that this competition/rivalry is actually healthy for the development of *good* window system ? Do you think that (unix-illiterate) consumers will be confused ? It seems that it is easy to spread FUD by saying that this will lead to several linux X application/API fragmentation .. we know thats bull but Tom, Dick, Harry and Sally may believe it.
There's been some mention of a new KDE browser effort in the press recently. This is great, as the browser is such an integrated component of KDE and yet the current one doesn't support (e.g.) authentication.
Was there any consideration given to using Gecko as the rendering engine for this?
I'm using mozilla (M11) to post this, and the rendering engine seems pretty much all there now, in fact there's enough working that I find the browser side more stable than Netscape (although not always as functional).
Also, on the endless KDE / Gnome / just a WM choice: I have tried KDE and Gnome both, and found that the tight browser integration caused too many problems for me and I consequently switched to Gnome where the browser isn't so tightly integrated.
I still find myself using a 'KDE' application for building web pages however (webmaker) and that works just fine under Gnome. I've looked at other KDE applications and found that they don't work so well under Gnome though. Why is this? I'd love to see KOffice work OK for me :-)
Are these non-working applications using more features provided by the KDE window manager, or some other part of KDE that I don't see?
Thanks,
Andrew.
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...
I understand the reasoning for KOffice, since Star Office isn't open source. However, what is the motivation for developing another browser? It seems to me that Netscape already has become the standard for *Nix platforms as far as web browsers go, and it suprised me that the KDE team was working on a browser now that Netscape has an open source project. Is browser/file manager integration (which I assume will equal functionality similar to Windows/Internet Explorer on windows without the crashes :-) ) that important? Is there some special niche that Konq will fill, similar to how Opera focusses on being speedy and lightweight? In short, what is the justification for re-creating the wheel?
(Sorry if any of these are repeats)
;-)
- Are there any tutorials for QT/KDE programming?
- Is there anyway Joe User can help with KDE2?
- Are there any aspects of GNOME you wish KDE had?
- Many aspects of the KDE interface have a WinNT look and feel(imho). Any particular reason why you went with that style as to MacOS or BeOS?
- Q3Test or UT?
Thanks for a great UI...
--------------------------
-=-=-=-=-
-=-=-=-=-
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.That appears to be the Qt Way of handling printing.
It is interesting to contrast with other methods that have been used historically and recently:
It is not clear whether or not KDE is using the QtPainter facility, or whether there is need for something like GNOME Canvas...
If you're not part of the solution, you're part of the precipitate.
The technology I'm specifically referring to is the Workplace Shell, OS/2's default UI and an example of a properly implemented OO UI. The Windows 95, 98, & NT4 UI tries to fake an OO desktop, but it's skin-deep at best.
The WPS' "desktop" is the master object... everything else in the UI is a refinement of that object. It is possible to change the attributes of entire parts of the desktop simply by changing parts of one object higher up in the object heirarchy. I know I'm not really explaining this very well... one of the other people in this thread gave a link to a good article explaining how an OS/2 company created a product that didn't contain any executables other than the install program, and I'll reprint that link here:
http://www.byte.com/art/9602/sec16/art1.htm
Among other things that the WPS allows you to do:
full drag and drop: you can push a file onto an application and it'll activate the application appropriately. In other words, push a text file onto a text editor and it will open the file for editing. Push a text file onto a fax icon and it will activate the fax machine (without opening the program first, if the program is truly WPS integrated). Push a text file onto a printer and it will print out the document directly.
Right click on an object and you'll get a context sensitive menu for that object (which may differ from other objects -- i.e., files and folders would have different options because they're used for different "things")
If you create a program link (an iconic representation of an application) and then move the application to a different location in your file structure, the link keeps track of the new location and updates it automatically.
Of course, one of the less useful but more fun aspects of this is the almost infinite ability to cusotize everything. You can give every folder a different background color, a different font, a different bitmap. It's possible to make certain objects conform to one color scheme and other object conform to another color scheme.
Yes, all these things can be done without the benefit of an OO environment, if you hard-code everything individually. But the way the WPS is designed you need only alter parts of some objects, and the changes cascade down through all their child objects. Very nice.
Eviscerati.Org: All Hail the Eviscerati
For example, after trying to install a recednt version of ncurses, I find that anything that uses ncurses now dumps core for me like this:
This includes essential programs like talk and lynx. And because this is Linux, I can't just type to fix the problem. Curses! Foiled again!Remarkably enough, I did finally get enlightenment working. Considering that the behemoth links against twenty-one (yes, that's 21, 3*7) different libraries (try running ldd against it), I'm pretty surprised it's working. Well, somewhat working. It refuses to call up the Gnome configuration tool anymore after the 0.16 upgrade. The RPMs ate my program, again, Teacher. I didn't touch it, really! It won't tell you why. You can't find any error messages. No place to trace it down. No complaints. Just. Plain. Nothing.
The abyss.
After a day of doing that and finding that the harder I tried, the behinder I got, as Redhate Linux configuration bitrot sent my beloved system spiralling into unusability, I decided not to throw good money after bad--to quit while I wasn't ahead, as it were.
So you can begin to imagine the tears of joy that streamed from my eyes, when, on my happy BSD system I typed:
And it worked. It fricking worked! It just did absofuckinglutely everything and it all worked! It fetched everything needed, in pure unmutilated source code. It never blew up because something wasn't there, it just obligingly fetched it, built in, installed it, and kept going without missing a beat. Not only did it work seamlessly, it managed to so without trashing my entire system.I laughed. I cried. I giggled and gibbered with joy. I spat upon the parts of the disk on the Linux box where I thought the wicked RPMs lay smoldering. I sang praises to the mercies and the glories of the Source, whence all solutions come. The heavens themselves opened up, and the epiphany that seized me was nothing less than the full force and fury of the power of the Source. Blinded by the light, I heard the source angels trumpeting from on high (in D major): Death to RPMs! They are the Dark Side of Winix! They will destroy you! Return to the source, brother! Glory be to the Source! By Source alone are you saved!
Ok, deep breaths. Much better. I'm calm again.
I wanted you to know that you did suffer alone, that I too know intimately and painfully whereof you speak. I too have walked the Via Dolorosa that you describe. And I just wanted to share this blissful and fleeting moment of, um, enlightenment with you. :-)