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.
At least until I've had a chance to upgrade my SuSe install to KDE 2.0 and exercise it a bit. Then I'd be able to ask some good questions.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
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.
I've been using KDE for a long time now. I tried out Gnome, and what I didn't like about it, is that it is completly bloated. I have taken a look at your screenshots for KDE2.0 and it appears your heading to that same bloated environment. Will you still offer the ability to shut off all those eye candy features, like transparent terminals, to make a slim desktop environment?
"Out, OUT! You demons of STUPIDITY!" - Dogbert
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
How much cooperation (and integration efforts) is there between the KDE 2.0 developers and the Magellan developers? I think Magellan is as exciting to KDE users as KOffice, yet we don't hear much about the former while we do get occaisional news about the latter. Secondly, does the KOffice team have any plans to become a drop-in substitute for MS Office? We are an NT shop right now but have our eyes on Linux on the desktop (already have Solaris in the server room) and this functionality is key to having our people productive cross-platform.
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
When will they drop QT ?
License issues:
* you can't fork QT development.
* you can't make commercial software with QT without having to pay Troll.
Technical issues:
* QT is C++, which makes it harder to program it another language than C++.
* QT imposes (or at least strongly encourages) the use of a preprocessor which painfully reminds of MFC.
Mathias
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.
This question addresses the relative strengths of KDE and GNOME. Clearly, KDE is a much more stable and efficient environment than GNOME, but in the area of customizability and user-frienlyness, GNOME is still ahead. I was wondering how much action is being taken to make KDE 2 more customizable and user friendly. In particular, I was hoping to see a better implementation of mime types being associated with programs.
There's no reason for a sig here.
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
We've all seen it, Win3.1->Win95->Win98,
Dos1->Dos? Office 95->Office 97... the bloat creaps in invariably with newer versions. Looking at the screenshots of KDE 2.0, I am a little worried. Is there a concerted effort to keep bloat to a minimum and make sure that KDE is available to those without 256Megs of RAM and PIII's?
But I must say, KDE (and GNOME) have made linux useable for the masses(aka. my Mom and Dad). Thanks
/* CDM */
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
There are many issues that continue to retard Linux's acceptance on the mainstream desktop. I have experienced a few that would have stumped a normal user to simply abandon Linux entirely. KDE was a fantastic first step toward allowing others a chance to peek into the world of Linux. In what ways, if at all, will you be addressing the new user with KDE 2.0? Will it be primarily from a documentation point of view, which would facilitate a smoother learning curve for new users? Or will you update many features (Kmail and Knews, and Kppp) so that they can quickly access the Internet in order to gain the valuable knowledge necessary to make the Linux switch?
Either would be a boon!
Myxx
----------
Twisted Little Gnome - The Podcasting Network http://www.twistedlittlegnome.com
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?
But I did not shoot the deputy.
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!
So, are there any plans to add a Eudora-like mode to KMail, or to create a Eudora-like mailer for KDE?
Alex Bischoff
---
Alex Bischoff
HTML/CSS coder for hire
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
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 have a couple of questions about the upcoming KRASH release:
- How "complete" feature-wise will KRASH be compared to the actual KDE 2.0 release?
- Will it be possible to run KRASH on the same machine with KDE 1.1.x without conflicts?
I know KRASH is supposed to be a developer's-only release, but I would like to try it just to get a preview of KDE 2.0.
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
I write a lot of scientific papers and presentations with tons of equations. Normally, I use LaTeX for all my stuff, and it works great. However, there are some people (like my supervisor) who are hesitant to use something like LaTeX because of the steep learning curve. They prefer to use GUI-based stuff like Word and Powerpoint because they are simpler to use and require less startup time. I am trying to convince them that there are similar tools in Linux but they seem somewhat unconvinced. I have played with KMath a bit, but from what I see, it still has a long way to go. I appreciate the complexity of this problem, but I think one of the things preventing me from recommending KOffice and/or KPresenter is the lack of a full-featured equation editor. If KMath were to move more towards something like MathType, a lot of people from the scientific and academic community would find KOffice a more suitable project. For all I know, this may already be improved in KDE 2.0. I can't wait to find out! Right now, I think StarOffice has the best equation editor for Linux that I've seen even though it is still a bit awkward to use.
.png images of all my equations, and then I embed these images into my KOffice/KPresenter document. This is somewhat of a roundabout way of doing this, and I wonder if there is a better way to get the same results with less work? Will KDE 2.0 make this any easier?
My question is basically:
What work is being done to make KMath a more powerful equation editor (more like MathType from the Windows world)? Is it likely that there might be some integration with LaTex or LyX? I would like to see it possible to embed LaTeX-like code in the document to make prettier equations. Right now, I use latex2html to make
(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!
Two Questions: 1. Can I expect KDE 2.0 to be significantly faster and less resource hungery that previous versions? To everyone I've demonstrated KDE to (unless on P-450s), those problems have been immediately noticeable...especially when compared with Win95 on the same machine. 2. Has there been any re-work to resize dialogs to accomodate at least 800x600 resolutions? Many people still prefer that resolution, because they hate tiny fonts and icons... I don't like the large dialogs even on 1024x768, cause I'm trying to do as much as I can on my desktop without having to flip screens constantly.. Or are these two issues unmentioned or ignored? --Matthew
Perhaps this is a re-hash of previous questions, but with the many questions about QT, it's appropriateness in a GPL'd project etc, I wondered how much KDE NEEDS QT, IE would KDE require a major re-write to support some future GPL'd library? Or is it modular enough to abstract away the particular GUI lib?
The fact that no one understands you doesn't mean you're an artist.
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 was very excited to hear that the 2.0 release would contain a web browser. I and many other linux users are completely fed up with the current applications available to us. Is Konquerer going to be a full-fledged browser supporting all the technologies that make the web work (CSS, Java, Javascript, XML, etc)? In other words can I replace Netscape with this browser or will I still need to load it up for some sites? If it's not fully-featured now then will it be soon and is it uasable as-is? (unlike Mozilla... bah I know I'm going to get it for that one)
<SIG>
I think I lost my work ethic while surfing the web. If you find it, please email it to crispy@crotch.caltech.edu.
</SIG>
My sig has a broken link in it.
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
Those questions about OO technology and QT and MS-Office alternatives are all well and good, but let's get down to the important stuff...fun and games!
.kss stuff is all well and good but there's a world of eyecandy out there that we can't easily use in KDE.
What, if any, new games are going to be included with KDE 2.0?
How about putting in an Xscreensaver interface like Gnome? The
Time's fun when you're having flies. - Kermit the Frog
I'm a KDE user who likes Gnumeric. How would you compare the two in terms of features and stability? If Gnumeric is much more advanced than KSpread, would the KDE organization consider integrating it into KOffice as the default spreadsheet app?
I'm being funded to help make an office package useable by blind and visually impaired (V.I.) users, and I haven't chosen which office environment to work with yet. Making software useable by V.I. users is a very similar problem to adapting software for mobile computer use, where you have limited screen real estate (handheld devices), and possibly no screen at all (as in a car - or as in StarTrek). In the past, people have tried to help V.I. computer users by writing special software that lays on top of Windows programs to try to re-interpret the visual interface into speech output. This is not an easy task - and results in a less than perfect solution. GPL gives the disabled community an opportunity to alter software for a variety of environments from the inside out. The added flexibility only enhances the desktop users experience - for example, a better keyboard and speech interface. Personally, I don't like having to move my hands from the keyboard to the mouse and back. As a sighted user, I would still to do some basic computing while on a roadtrip - such as reading, writing and browsing. It's not as complex as it sounds - the experience of blind computer users could be helpful to get us there. From a philosphical point of view, it shouldn't matter what input and output device a user wants to use (speech? sign language?) - software should support these alternatives from the core. What I would like to know is - what is KDE's philosophy on disabled and mobile users? Have you had any interaction with users with special needs who want to access the KDE interface? I think this would be an area KDE could attract some really good press - MSWin and StarOffice do little in this area. (StarOffice does nothing, and MS thinly supports disabled users - only enough to keep from being sued under the Americans with Disabilities Act). I think an open source project like KDE could attract some very talented disabled developers who need useable software! Aaron Leventhal
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.Given that, for the inprocess case at least, you've abandoned CORBA for shared memory in KDE 2.0, have you considered alternative component technologies such as COM, the Component Object Model?
Aside from the fact that it was created by Microsoft, I've found it to be a rather useful. It's fairly efficient for inprocess use (the overhead is only that of a C++ virtual function call, assuming "client" and "server" are in the same "apartment" (in COM-speak), and is language-independant -- assuming you can get a compiler to create the appropriate C++ virtual function tables. GCC-2.95 just happens to be such a compiler. (You need to use __attribute__((com_interface)) in the class declaration.)
It can also be extended to work cross-process and cross machine by implementing proxy and stub DLLs/shared libraries.
The only downside is that there is no free/open-source COM library implementation that operates under Linux. However, it's fairly simple to implement a subset that works on all platforms -- Mozilla does this through it's XPCOM libraries for all inter-object communication.
Just wondering if any other choicse were explored in the decision to drop CORBA...
- Jon
From a programmers POV the KDE gui is 100% Object Oriented since it is written in C++.
From a users POV, the embedding of applications (when I click a picture-icon a viewer is started and embedded inside the requesting appl) is nothing short of a OO methaphor. The way of working is indeed based on the workbench methaphor which is around since Xerox started that..
I understand that BlackBox and Windowmaker are currently KDE "aware", but are you working with the people who maintain them to make them more interoperable with KDE 2.0?
Which direction are you guys headed with Kwin, other than the stated purposes of skinning and cutting down on the memory load?
Finally, have you considered(and please forgive me if this is asinine) setting up a way to install a kind of KDE "Lite" that uses fewer resources and has less core function, but runs on older and less powerful machines?
Cuchullain
"If sharing a thing in no way diminishes it, it is not rightly owned if it is not shared." -St. Augustine
No doubts, Gnome looks slow and unstable in comparison with KDE. But, the funny fact, I'm using neither and staying with good old FVWM. Call me an old-timer, but there's the only thing that prevents me from switching to KDE: limitations on the virtual desktops.
I have 36 of them (6x6 grid) since about 1994, and here's a breakdown:
12 xterms, everything else for Netscape or any other applications.
And believe me, 12 xterms is *almost* enough, and definitely not too many.
But, the KDE supports (supported?) only 8 desktops, and forces me to 4Wx2H grid, instead of giving me a freedom to configure it the way I like.
Gnome does it, but their pager lags for some reason (maybe they thought the lazy redraws makes the apps appear to be faster?) and that is the pain in the neck - the chances of getting lost for 10-15 seconds once in a while are quite real.
So getting back, is it that difficult to implement a flexible desktop layout scheme with a pager that doesn't lag?
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.
In corel Linux there control panel has both video editing (i.e. you can change the video mode, res etc) Also it had networking in the control panel. These really cool features made me almost reload my machine just to see how it worked. But my big big question is are these going to be in the KDE control panel. I noticed this "feature" was apsent the first time I used KDE. Also the icon is of a monitor and a card. Just a though. OR can I simply take corels and install the deb and have that feature? Will it be in 2.0? I am not the only one who is wondering this. Just about everyone that I have been talked to in the last month have discused this with me at some point. Benjamin Meyer
But are you sure its wise to develop an entire new scripting language, kscript, which seems to be part of koffice. As you know, there's no shortage of scripting languages out there already.
I suggest you revisit your earlier decision to move away from an established language (I believe at one time you were going with python). Perhaps some the reasons to abandon python have changed, like no longer having to get it to play as nice/efficiently with mico.
At any rate, you need to present a good case for your scripting language, be it kscript or other. And don't restrict it just to koffice! Good scripting is a powerful feature.
Why is the KDevelop program and the whole KDE project in general trying to mimic MS libraries, technologies, concepts, and GUI?
:)
Wouldn't we then carry over all the bugs and incapacities of many Windows applications written in VC? Also, will not the KDevelop carry the limitations of DevStudio IDE ? Do you think that the way MS programs and libraries have been designed is, at any rate, optimal, or at least highly satisfactory?
Are you assuming that MS is really going the right path, and all we should do is to copy, verbatim, what they do? Then, why not imitate every MS windows app out there and add 'K' suffix (Change KDevelop to KDevStudio perhaps) ?
I'm asking these questions as a programmer who has worked 1.5 years on NT4.0/VC50 so I really wonder what they think since my sufferings were incredible during that period of time.
--exa--
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?
My hope is that a standard will grow out of both projects, since I feel is that while desktop environments should not be standard (KDE, Gnome, etc. should all be out there and flourishing), component object models should be standard. So how do you standardize while "competing" with Gnome? Or am I wrong, and standardization is not necessary here? If a later standard component model is agreed to, can you afford to rewrite KDE, or will this essentially mean throwing the whole thing away? Are you backing yourself into a corner with KDE2?
Will it be possible to turn off session management? A major reason that I don't use KDE is that it wants to restore my previous session. I personally prefer to restart all of my apps through my .xinitrc (or perhaps through some kind of explicit startup mechanism); I really don't want my previous session restored automatically.
Ok, I thought I understood things but some of these questions have confused me. I thought the layers to GUI under *nix was basically:
1) X protocol (gui agnostic)
2) Window manager
3) Toolkit (at application level)
Now items at levels 2 and three can be swapped...i.e., you can choose whatever window manager you want, and under that window manager, applications can use whatever tookit they way, more or less. Now, where do GNOME and KDE come in. They appear to be somewhere between 2 and 3. Are they simply "glue"/abstraction layers? Certainly they're not replacing XFree are they? And what is the meaning, and point, of choosing window managers under KDE or GNOME? Don't KDE and GNOME handle the look and feel? It would seem that if I could choose whatever window manager I wanted, and applications could choose whatever toolkit they wanted, that I'd have a pretty ugly, non-standardized, incompatible mess of a GUI. How does this work?
It's 10 PM. Do you know if you're un-American?
They appear to be somewhere between 2 and 3.
=
They appear to be somewhere between 1 and 2.
Man, I really can't type today...
It's 10 PM. Do you know if you're un-American?
ini files were one of the best things that ever came out of microsoft. There's a reason they've lasted as long as they have. IMHO, they are far better than any rc file. The ability to have multiple key/value pairs grouped by section is wonderful. If the item is not there, the function returns null.
With an API for this, programmers never have to write their own config file logic/access methods. If you look at your kde rc files, they are in fact the same as ini files. The kconfig class goes one step further; It does not just read/write key values/pairs in groups. You can tell it to write more than strings. You can pass it a QFont object, and it will write the font string (XLFD -- X Logical Font Descriptor) to the file.
Just how easy will it be to get the thing installed and running the way you like it?
With my experience with GNOME/Enlightenment, I love to play with it, but it takes a lot of tinkering and scrounging for answers through countless FAQ's, mailing lists and (limited) documentation, then searching out and downloading tons of prerequesits before you can install it. If everything doesn't work perfectly (which it never does), then comes troubleshooting... you may need a *lot* of time on your hands.
So for the non linux-guru, just how easy will it be to install (or upgrade/switch desktop environments), configure (like behaviors, sound, printing, etc.) and troubleshoot?
I realize a lot of these issues have to do with the maturity of Linux itself, but this is a good topic to discuss!
-Monte
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
I think the folks producing the KDE should be congratulated for making a product that's friendly enough that beginners can use Linux for basic network and productivity tasks. What's now lacking is a Linux environment for those in between the novices who don't want to reconfigure anything once it works and the pros who don't need a desktop environment.
Intermediate users are still stuck with issues like critical configuration files having obscure names and locations, a bewildering directory structure, an inability to reorganize applications and support files according to their needs, etc. Although many of these are more structural issues with Linux as a whole and many *nix programs in specific, has the KDE team ever thought about turning their attention to making Linux as a whole a bit more user friendly, or at least providing a shell that makes it appear that way?
Jay T
______ This mind intentionally left blank.
In my experience Gnome has been much more snappy in my 200/48 Mb pentium, conversly KDE is not usable at all, it doesnt't stop swaping a real nightmare to use.
The Linux viavoice is basically just an SDK right now, however the Windows implementation is very very good. It works incredibly well with MICROS~1 Internet Explorer. Are there any plans to design Konqueror and KDE to facilitate the use of a voice interace API (such as ViaVoice SDK)?
Mandrake also for some reason puts KDE in /usr!!! This is extremely confusing and results in a total mess. Besides, shoving KDE in a non-standard directory creates a lot more work for the Mandrake developers...
/opt/kde!!!!
It is my biggest gripe about Mandrake.
If there are any Mandrake developers reading this, *PLEASE* put KDE where it belongs -- under
___
If you think big enough, you'll never have to do it.
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
After the recent feature on /. about the Konqueror browser I probably wasn't the only one who was impressed by what you did with such few resources when compared to Microsoft or Mozilla.
However, I have an issue with it: As Konqueror seems to have a lot more features than the really limited HTML widget in KDE 1.x, aren't you worried that Microsoft might take it as an argument in their current case vs. the DOJ that a powerful Web Browser really belongs into the operating system?
Also, how will you ensure that malicious active content (mainly JavaScript-Trojan Horses/Viruses like Bubbleboy) will take advantage of the tight integration between Konqueror and the rest of the system to endanger security on the Linux platform as a whole (especially since the MSIE/Outlook Express developers have proved it more than once that adequate code validation isn't possible and does always leave room for just one more backdoor)?
I'm not a programmer, but I hang around on a few mailing lists.
I remember a year or so ago, GNOME was using mico for their ORB. This caused problems, as at the time mico was slow and had way more features than GNOME needed. Hence, GNOME uses ORBit these days instead of mico.
I've noticed looking through the KDE download areas that mico is still there, and I was curious how well mico works out. Has it improved as far as speed goes, or are you planning to switch to another ORB eventually? Speed is a very important factor, and as KDE becomes more object-oriented, a slow ORB will reduce preformance considerably.
Those who can't do, teach. Those who can't teach either, do tech support.
I've heard that KDE2 will come with a new window manager called KWin and a new panel called Kicker. Can you briefly describe the new features and advantages these have over the old window manager and panel included in KDE1.1? Thank you.
--
For every post, there is an equal and opposite re-post.
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.
Will Konqueror be able to run standalone on non-KDE desktops? How embeddable will it be? How does this apply to other KDE Apps?
This question applies equally to Gnome, but this is a KDE interview.
Unix design has always gone with many stand-alone components. The command line is a bewildering array of tiny programs connected by pipes and the shell of choice. The graphical environment is similar. One can pick and choose between different X servers, font servers, window managers, and so on.
I don't see this with the desktop environments. True, one can pick and choose dock apps, but what about the rest? I don't see multiple D'n'D servers, each caring little whether KDE or Gnome or nothing is running. I don't see tiny apps competing for the right to manage icons on my root window. If it's possible to replace a significant part of any of the desktop environments, i'm not aware of it.
Am I uninformed? Are we continuing the designs that have made *nix what they are, or are we recreating the monolithic designs that still frustrate us when we're forced to work with them?
sklein
I've noticed that KDE2 (at least KOffice and kdecore) don't link with mico anymore. Are you planning to completly replace CORBA by more lightweight IPC?
Opus: the Swiss army knife of audio codec
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!
Firstly, congratulations on the incredible job you've done with Kdevelop.
While there are a couple of external widget repositories for KDE, there seems to be no documentation or abstraction of many of the widgets used in the base installation and initially installed tools. Is this going to happen, or is KDE still too fast a moving target for application developers to make use of this code?
---
Silence is consent.
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.
Wow. I couldn't disagree more. I use KDE all day long at work (and GNOME at home) and I loved what I saw in the KDE 2.0 screenshots. To each his own.
I once worked with a guy who couldn't stop talking about how wonderful OS/2 was. He even talked me into going to the Warp rollout put on by IBM. While we were there, they gave out door prizes. My buddy was one of the winners and he went home with a brand new copy of OS/2 Warp. A couple of weeks later I asked him what he thought of the new version. He said he hadn't installed it because he couldn't really think of what he could use it for.
The customizability and intuitiveness of the WPS keep me running OS/2 years after IBM decided it would be better off dead. Of course, I still boot up Debian when I want to develop (free) software.
Have you had or will you be having discussions with other SW publishers (both OS and proprietary) about ways to integrate their products into the KDE environment? That is, if, say, Bioware wanted to develop a Linux version of a game would they be able to get assistance from your team?
Yes, I know that they could just read the source code, but one of the things that keeps Mac (and, to some extent) Win programs consistent is that the UI designers can discuss their design decisions with other vendors and make it easier for them to port their applications.
Along those lines, how evangalistic are you at presenting the KDE environement to folks/companies who may be interested in Linux, but just not sure where they fit in or how to get their apps up and running? Do you even think that this should be part of your role?
A lot of the time, KDE and GNOME seem to follow somewhat-different courses to very similar ends. I understand there are probably some philosophical differences in the code used and so on, but from a functional point of view, would the projects benefit from something a little more cooperative, perhaps creating a modular environment where users can pick and choose their functionality, or where the underlying interface could be tailored to accomodate whatever methods a particular developer preferred?
-Drayke
-Drayke
If all the world's a stage, it must have been an easy audition.
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
Why not do something for the Linux desktop?
I have seen 99.9% of corporate desktop computer users either live within Lotus Notes or MS Outlook. With a small percentage actually creating anything other than an email. MS office is there on every desktop but is not really used beyond updating resumes, or spell checking..
When will there be a Knotes or a Koutlook?
Get a free ipod.
uhhm, Mandrake installs kde under /usr, and *not* /usr/kde. /usr/kde, there would not be a big problem. As it stands now, if you look under /usr/share directory, you'll notice a whole bunch of stuff half of which belongs to kde and the other half doesn't. While you can certainly create a symlink /opt/kde -> /usr, it will not solve any of the mess.
If it did put it under
___
If you think big enough, you'll never have to do it.
While I don't mean to come off as a troll, I would like throw my opinion into the ring. I think that this whole approach of seperate projects for major OS components is the wrong idea. I know seperate projects is Unixish, but there is a reason why Unix did not make it to the home market. If we just emulate Unix, Linux will end up being a Unix. Something like windowing system should not be its own project with half the system RAM devoted to it along with 40MB+ of code. It should be a collection of clean, fast, low-level libraries tightly integrated with the kernel and other services. I think the whole problem with things such as X and even Berlin, is that they develop it as a application instead of as part of the OS. Also, so many services should not be built into the graphics system. At the moment, X is even worse than the GDI. An idea would be to make a multi-threaded graphics/windowing library that interfaces directly with the kernel. Have this library support client programs via different threads. Secondly, have GUI services as entirely seperate services independant of the GUI itself. For example, the kernel would handle low level details, while the graphics system would interface directly with it and the graphics driver to do low-level graphics. Then the windowing system would interface with the graphics system to do drawing. Or for more performance, pull drawing and windowing into one library. This windowing library would handle the bare minimum needed to draw windows and text, and images. Then higher level services such as font conversion, graphics conversion, etc, would be handled by another library, kind of like glibc. Even higher level things such as applications frameworks and object embedding would be handle by still other services. Thus the need for a "desktop" manager dissapears. Also, bloat is kept out of the lower levels of the system. (ehmm, X, cough...) There is no need for so many projects to be dedicated to doing what should really be a simple and low-level job. You don't see mutliple projects for the ide drivers do you?
And this seperate project stuff DOES lead to bloat. What is KDE? Is it a window manager? A service that offers embedding functions? And application framework? This could be implemented in other areas as well. One place where windows has the right idea, is in drivers. Drivers should handle all tasks needed to make the device work, and should have a standerdized interface into the system. No more of the wheel program needed to use the wheel on the intellimouse. I realize that this would probably be a long term project, but in the end, graphics performance will demand low OS tax. The applications should use the most processor time and memory, not the OS. And yes that does sound a lot like Windows and BeOS. Thats because it IS a lot like Windows and BeOS? But think about it, shouldn't thousands of hackers really be able to make a graphics system outperform the GDI? (Graphics Device Interface, for those non Win32 programmers out there.)
A deep unwavering belief is a sure sign you're missing something...
First I'd just like to say that I have been using KDE as my full time working environment for almost two years now, and it has completely satisfied my needs for a 'nix GUI. I congratulate all the KDE developers on a job well done.
Now for the question: What direction do you see KDE as a whole progressing to in the future? How would you compare KDE's future to the other popular desktops systems in use (with both the Linux desktops such as Gnome, and also the Microsoft offerings, such as Windows 2000, etc.)?
While KDE is nice, it lacks the consistency or functionality of even Windows. I think that a balance between the ability to configure the desktop and make things work in a consistent manner would be incredibly good.
Right now KDE and many of the other window managers borrow many ideas from countless OSs. While this is looks pretty, it hasn't been implemented in a way that is seamless.
Form over function is the name of the game right now. Once that changes, the adoption of KDE and others will rise dramatically.
I don't agree with people wanting to loose Qt
from KDE. Qt is one of things that made KDE possible.
Qt has a great design and even better documentation. What's more it's commecial grade software that you get for free. (Provided of course that you aren't commercial yourself, if
you are commercial then of course you should pay them, just like you want other people to pay you).
What Qt doesn't provide is an application framework. The folkes Toll tech I think believe
that corporations (their customers) will develop their own in-house application framework and my
experience is that this is what happens. The great
thing about KDE is that they are providing this
application framework for the rest of us free software source code hugging lackies.
Oh yeah, KDE is also demonstrating how cool their application framework is by producing inter-operable applications.
Microsoft tried hard to address this inter-operability common look and feel thing, and they are still trying. They had the difficulty that they were Microsoft but still did some neat things. Now KDE has the opportunity to make a significant contribution to this area and I think they will.
I see the challenge facing KDE as: Create an open standards framework that allows a high level of co-orporation between applications.
i.e display this data for me. Print this, play that. Fetch me this, that data just got updated etc.
I think the KDE group are already a long way down this path and by producing the suite of applications they are they can give their framework the impetus required to get people using it.
Your comment about printing reminds me of the main item keeping ME from converting to Linux: the need for a version of Money or Quicken or the like. (Perhaps someone should start a list of all the "Windows anchors that keep us from adopting Linux.")
I run virtually my entire financial life with Micro$oft Money now (paying bills automatically via CheckFree, downloading stock quotes, updating my investment portfolios, etc.) In fact, this represents one of the few real-world purposes for which I frequently use my PC.
Until some replacement exists for Linux -- or until the Windows version will run successfully under an emulator for Linux -- I have no choice but to remain a Windoze user.
The Crayfish
The Big News Page
I was pleased to read that KOffice would be scriptable in Python. Then I was disappointed to find some documentation on the KOffice site which seemed to indicate that something called KScript would be used instead. Is this true? If so, why?
--
I understand both Gnome and KDE are based on ORB's specifically ORBit and mico. My question is what is the level of compatability of these ORBs? For instance if I am writing a server only portion of my ORB (doesn't use any GUI calls) will it compile with both KDE and Gnome? If not how much work would be required to port from one to the other.
Marriage is the "pseudo-ethics" that cloaks the messy truth of sexuality in the raiment of propriety -- it's "Don't Ask,
How do you think Linux windowmanagers will be affected by the MS breakup in the long term? If win32 api's were opened, do you think that support for some level of win32 emulation could be integrated into KDE? What would this mean for K-specific applications development?
KBiff doesn't seem to have much by way of command-line options, certainly no -help or --help, and does many non-intuitive things.
While it's being tinkered with, I would value the addition of a -dont-popup-the-damn-config-window command-line option.
Got time? Spend some of it coding or testing
Yes, I understand what you're talking about with RPM'S introducing library incompatibilities..
But there's nothing that says that you need to use binary rpm's in the first place! Just do what I do...download the source for EVERYTHING, compile it once, and never have library problems again...
Any time I have had a library problem, a simple recompile fixes everything.
Debian's apt-get will grab the source for you in the same way that BSD grabs source for you.
Mozilla promises to fix some of these problems, but nevertheless still seems to be trying to be an all-things-to-all-men browser. This is one of the attributes which makes Internet Exploder a security nightmare.
KFM makes a reasonable sort of browser and is quite light-weight (about 4MB plus libraries offhand) but still muffs tables badly on occasion, often responds to a redirect by closing (OTOH it displays PNGs better than Netscape), and isn't too savvy about HTTPS protocol.
Konqueror, I gather, fits the still-rather-broad niche between these, as Mnemonic fits the showing-equations-right lightweight browser niche.
Got time? Spend some of it coding or testing
How will developments such as Kylix (Delphi for Linux) affect KDE? Would you be tempted to rewrite some bits in Kylix?
unlike Mozilla... bah I know I'm going to get it for that one
Are you? I downloaded M11 and it promptly leaked memory until it drowned itself after about ten minutes. It still doesn't do HTTPS as far as I can see, but OTOH handles forms a lot better than M10. I don't like the Explorer-ish bookmark panel.
Got time? Spend some of it coding or testing
After a browser/email kit and office suite, the next application I see most often on Windows machines is an accounting package. Are there any plans for, er, Kbucks (?) - an internationalisable accounting package?
Got time? Spend some of it coding or testing
Will KDE2.0 Apps have Gnome integration? That is, will the apps (konqueror, KOffice, etc) run OK under Gnome, or will we have to use KDE in we want to use these (what will be very fine) applications.
Will then even require KDE/Gnome at all? Will these apps be capable of running under, say, basic fvwm or twm, for those memory-challanged PCs?
Keep up the good work
T.
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.
Excellent putdown of of sad xenophobe. Well done.
"Captain, I cannot believe my ears!" - Spock
This version of KDE will probably come without Katabase; when do you estimate will we see a user-ready version?
Most interface studies seem to focus purely on how easy it is to get up and running. Unfortunately, when you become more familiar with the environment, you are stuck with a UI designed for new entrants.
WPS was not so easy to use first up (on Warp 4 it was much easier than OS/2 2.0). But, the more you used it, the more you found out, and the more you realised you could do just about anything. For an advanced user, it is way ahead of anything else around.
Unless you've used it for about 6 months or more, you don't get to fully appreciate what it can do.
I'm just saying the C++ != OO.
That's a bit harsh...
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.