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
What kind of features will the Konqueror browser have? Do you expect it to be something on the level of Mozilla or better, or will it be less feature-loaded initially?
mikre he sophia he tou Mikrosophou.
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
Do you ever see KDE being workable for both new users and power users? Do you think KDE will eventually be the most popular *NIX desktop? how do you plan on achiving this?
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?
I'm therefore a little concerned about how KDE handles the de-facto standards for Linux programs - it seems to me, like, saying: "GUI is the most important thing, and we want it to be "a better Windows".'' Well, I don't. I don't want my rc files look like some Win 3.11 ini files :-) so to say. Don't you feel sometimes that you head for the "more-features-more-gadgets" road? I mean, it's nice to have this or that, but I don't want to abandon what I learned, and I don't want Linux abandon Un*x philosophy, which is, in my eyes, slightly different. A tiny example: why doesn't the commandline from kwm have a history / tab completion / anything that could make it seem a little different than dos?
Note, that I'm using KDE every day and I like it very much. I just - I am just concerned, that's all :-)
Regards,
January
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 have some questions. How does KDE plan on reconciling the differences between the QPL and the GPL? Source modifications apparently can only be released in the form of patches, and Stallman says it is incompatible with the GPL. Also, what are the terms of the rumored version 2.0 of the QPL? Or is there even such a thing?
:) Is this possible?
Also, will KDE 2.0 have the ability to drag and drop objects between KDE/non-KDE applications? I keep hearing about an old drag and drop protocol in X, but I never see any apps actually using it in any way I can tell. KDE does it with kfm but I'd like to, say, drag a mp3 over to koffice and have it embedded, or to kmp3/xmms/gqmpeg and have it load up automatically.
thanks
--- Grow a pair, liberals... stop letting the Republicans bully you!
It's still based on a non-GPL toolkit set... With that in mind is there any move to switch over to a GPL licensed toolset (Gtk comes to mind). Or are there discussions with Troll Tech to have them release a GPL'ed version of QT?
What's your opinion on the never-ending License Wars around KDE (the QPL/GPL incopatibility etc)?
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.
Swappable windows managers is one reason why X has remained fresh all of these years, and I'd hate to be commited to one just to use a particular application.
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.
You should check out Fetchmail. Although I've never used it with an Exchange server myself, the FAQ says that it supports Exchange servers. The beauty of Fetchmail is that it lets you use practically any mail client with practically any mail server. I started using fetchmail because MIT's mail servers use KPOP which very few mail clients support, and fetchmail supported it beautifully. I use Netscape Messanger to read and write my email, but practicaly any other mail client that runs on Linux will also work with Fetchmail (as it uses the standard mail spool).
As a nice added bonus, Fetchmail can transparently check multiple mail accounts at different intermittent intervals. So now I can check my ISP mail account, my main mail account, and my work mail account on a regular basis without having to think about it. When I used to live in the world of Windows I only checked my ISP account about once a month because nobody ever sent me mail there because I never gave out the address. Well, one day my ISP sent mail there because the credit card they had on file for me had stopped working (my bank had issued me a new card for some reason and cancelled my old card before its expiration date). Anyway, I didn't get this email in time because I checked my account there so infrequently and so one day my dialup account with that ISP just stopped working. The moral of the story is that if I had been checking that account regularly I could have prevented the problem. Now that I use fetchmail this problem will never happen again because I've set up fetchmail to regularly check all of my accounts and it takes zero time on my part.
That was just a fringe benefit, though, and it would probably be a fringe benefit to you as well. The main point is, Fetchmail can be used with Exchange servers.
-----
Free P2P Backup, Windows & Linux
PS The two links I included are just examples; I don't mean to single those two out ;).
Alex Bischoff
---
Alex Bischoff
HTML/CSS coder for hire
"* you can't fork QT development."
You have to do it in a different way, but it can be done. But is there a need out there to fork Qt in the first place? I don't see any of the other free GUI kits forking.
"* you can't make commercial software with QT without having to pay Troll."
Bull! You're thinking of the old license, not the new-and-improved Free QPL license of Qt 2.x+.
"* QT is C++, which makes it harder to program it another language than C++."
There are good C bindings for Qt. But OO is one of Qt's strongest points. Why abandon it when with just a half dozen lines of code I can inherit a Qt widget to do what I need it to do?
"* QT imposes (or at least strongly encourages) the use of a preprocessor which painfully reminds of MFC."
Then you've never programmed in both Qt and MFC. I have, and there is no comparison. With three simple macros you eliminate 99% of the cruft that goes into MFC code. Trying to code in MFC without the ClassWizard(tm) is excrutiatingly painful. But I can do all of my Qt coding out of vi with no problem.
A Government Is a Body of People, Usually Notably Ungoverned
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?
I see video file playback software as an important application for a modern desktop system because there is more and more video content offered on the net, from low bitrate news clips to huge MPEG-2 movie trailers.
Unfortunately, there is no playback software for two of the three important formats ASF (specs),
QuickTime (site), only Real is available (with some flaws in the player, correct me if I'm wrong).
Remember that Star Wars trailer using the Sorenson codec and how nobody could see it without a Windows box or a Mac? I'd like to know if there are any efforts underway to create a replacement format (very hard) or convince the creators (one of them Microsoft, but hey, they're trying to establish a standard with ASF, so they at least have to pretend they're cooperating) to offer a player which can be integrated into X / KDE. The xanim author does his best, but the enterprises won't give him specs on their newest codecs.
BTW, anyone here know about an MPEG-2 player (for unencrypted movie trailers)?
There were rumours floating around that KDE2.0 or KOffice would be licensed under the Artistic License as opposed to the GPL. However, the CVS tree shows that most stuff is still under the GPL.
Considering that Redhat once declared distributing KDE to be illegal, and that Debian would include Qt but not KDE, all because of a perceived GPL incompatibility, it seems that the licensing aspects would be very important.
What are the core developers views on KDE licensing? Will we see major components released under the Al, QPL or other license? Is the compatibility problem even an issue with the team?
In other words, considering the GPL/QPL intermix, and paraphrasing RMS, is it wrong to share KDE with my friend?
A Government Is a Body of People, Usually Notably Ungoverned
(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...
--------------------------
- Selecting menu entries, popup or root or Start
- Entering text in text entry areas
- Clicking a small button with an icon on it
- Clicking a larger button with text on it
- Radio buttons, checkboxes, listboxes
- Keyboard shortcuts (combinations like meta-*)
- Editing a dotfile
Which of these control types need to be made the sole control for a type of functionality? (i.e. you tend not to have text input that can also be done by 27 radio buttons for each letter, but often icon buttons _are_ doubled by menu items, sometimes with a keyboard shortcut also available.) Which if any do you feel represents the preferred KDE method of doing things, and which if any are discouraged?Formats like AVI and QuickTime (and ASF if I'm right) are only a container for different compression methods. Usually, the latest (= best) ones are not supported by non-proprietary software because there is no documentation available. One example is the Sorenson codec I mentioned. Xanim does support QuickTime, but not this interesting codec.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
Do you have any thoughts on what the "next" desktop environment might be like beyond a windowing environment? Would it be possible to have any other type of environment?
----------------
"Great spirits have always encountered violent opposition from mediocre minds." - Albert Einstein
Co-founder and designer at Music Nearby: http://musicnearby.com
I know you guys have been working with Gnome to standardize a lot of things, but do you ever forsee a time when there will be either a standard API or abstraction layer that will allow application developers to write one app that will be either KDE or Gnome depending on the user's setup?
"There's so much left to know/ and I'm on the road to find out." -Cat Stevens
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.
What kind of support do you provide for localization and internationalization? Do the toolkit itself and all applications support locales (eg, ISO-8859-?), or is everything in American English? What support do you provide for real message catalogues? How much support Unicode for is there? Considering the profound differences--often conflicting and contradictory--in pictorial interpretations seen between diverse cultures, what are you doing to do to bring the idea of message catalogues into the graphical space of those funny little bitmapped icons and buttons? How easy will it be for an entire site to change the default configuration to use an alternate set of text labels, text messages, and graphical devices (buttons, etc) that make sense in its culture? What tools do you provide to developers and to administrators to facilitate this?
Would you say that the worst excesses of Troll Tech's licence were more or less palatable than the Open Group's attempts to hijack X11R6.4 work, via it's licence change?
If Troll Tech seem to be misbehaving, in some way, I hope you can at least see that some of the alternatives out there are a whole lot nastier.
Hopefully, Troll Tech can head into grounds that Sun and the Open Group fear to tread, becoming more open with time, not closed. However, I can't see them being overly thrilled with the idea, if all they get is pelted with rocks every time they make a move someone doesn't like. Under those conditions, diving for cover and staying put would seem the more likely.
Only politicians and dictators win unilaterally.
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)
Again, I know about this. But it can't play Sorenson, the codec that most QT material comes in. From the website itself:
Be aware of one thing: Quicktime for Linux won't read any of the movies you download from the internet. Quicktime is a wrapper for many different kinds of compression formats. What you know as "Quicktime 4" is really a distribution of libraries which contain certain compression formats not found in previous versions Quicktime. Regardless of the version number, each Quicktime distribution is able to read and write a basic set of compression formats that you can manipulate on Linux or any system not officially supported by Apple.
From a programmers POV the KDE gui is 100% Object Oriented since it is written in C++.
Just because something is written in C++ doesn't mean it is object oriented. I'm currently maintaining some C++ code that is not object oriented, and I find it terribly difficult to maintain. On the other hand, just because something is written in C doesn't mean it is not object oriented. I'm a C programmer and I write almost all of my code in an object oriented fashion.
I haven't seen the KDE code, and I am not saying that their code isn't object oriented. I'm just saying the C++ != OO.
Mike
--
Mike Mangino Consultant, Analysts International
Mike Mangino
mmangino@acm.org
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
First of all, I use, and very much like, KDE. However, 1.x at least, is rife with windowsisms, including many that made it into the 'user interface hall of shame' and then were duplicated in KDE. I'm talking mostly about the little utility-apps here, like the file-finder :)
and such. That's background, now for the question.
Is this a temporary situation, or a deliberate KDE 'design goal' to be like-windows? If some developer out there were to find some time outside of work to redo some of them with a new and non-'shame'ful interface, would that be accepted into the codebase, or is it considered that the group already did it 'right' and you only want other kinds of improvements? Is there room for a set of alternate-KDE utility apps, or do you want one true KDE look?
(UI design -is- largely a matter of opinion, so,
if you think KDE's utility apps are already just great, that's fine, but I get the impression that it was just easiest to emulate the windows way on a lot of things.)
--Parity
--Parity
'Card carrying' member of the EFF.
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. :-)
The next piece of good news is that I freed the encumbered readline library using my innovative freedline package.
Another piece of good news is that by this device have all the GPL-encumbered libraries everywhere been freed, rendering them useful again as LGPL'd libraries (L standing for Library, of course).
Finally, my last piece of good news is that since then I've found that there are at least three other readline implementations out there, which means that you needn't even use my device. But it would still prove efficacious in freeing other libraries encumbered with the GPL.
Be free! Be happy!
That's snarf-and-barf.
As you see, this "left" and "right" terminology is completely wrong. Last time I looked at KDE, it kept telling me to use left button and right button, despite the fact that this was completely wrong. You see, I always execute xmodmap -e 'pointer = 3 2 1', which takes care of that. But the stupid messages don't track this. That's highly stupid. You can either fix it to track this correctly, or you can stop using messages that discrimate against someone's manual orientation, as I have attempted to do above.
And yes, I actually am completely serious about this.
Arse! This was basically my question, but slashdot was so slow this afternoon that I couldn't submit it. I wanted to know about more than just language bindings, though. I want to be able to make KDE compliant apps using whatever language and toolkit I want. Are there any plans to make KDE more language and toolkit independent? How can I make my C/Gtk app KDE compliant? What if I'm just using Xlib directly? Or even FORTRAN and Motif? What do I need to provide KDE from my app in order to be considered KDE compliant, and what steps are being taken to let me do that from outside of C++/Qt?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
My question is: will we have to wait until KDE 3.0 to have true bidi support? KDE 4.0? KDE 2100?
OTOH if there's any remote possibility that bidi is possible to add to 2.x series, I'm more than willing to help.
FYI: MS and Apple both support bidi. Be probably does too.
--
Industrial space for lease in Flatlandia.
I am familiar with TAO, and with ILU, and certainly know of MICO and omniORB. I suggest taking a look at the GnuPaghe Project; they went through an ORB selection process, and waffled back and forth between TAO and MICO, leaning back towards MICO because of compile time memory consumption. The finding on TAO was thus: Huge at compile time; I haven't done precise measures, yet it surely eats about 700 Mb while compiling it. This may be an exaggeration on the hugeness of TAO; there have certainly been similar reports on MICO. I've compiled some bits of ORBit code, and found it fairly appalling how 1K of IDL turned into compiled object code a hundred K or so in size; for C++-based stuff to be more lardly is not too much of a surprise. If it takes 128MB of memory to compile Hello, World! that can represent a significant barrier to the widespread adoption of CORBA.
If you're not part of the solution, you're part of the precipitate.