KDE 3.0 Alpha1 Available for Developers

Dre writes: "Just a few weeks after the release of the rock-solid KDE 2.2.1, the KDE Project today announced the release of KDE 3.0 Alpha1. Targeted at developers who want to get a head start on porting or writing applications to KDE 3, the release is pretty much a straight port of the KDE 2.2 branch to Qt 3. However, for developers this brings an impressive array of new features to KDE, including new database classes, new data-aware widgets, improved RAD development with a much-enhanced Qt Designer, a new powerful regular expression class (with full Unicode support), improved internationalization support (including the ability to mix different character sets in the same text), bi-directional language support (for languages such as Arabic and Hebrew), multi-monitor (Xinerama and multi-screen) support, better integration of pure Qt applications into KDE, and hardware-accelerated alpha blending. With the Qt port out of the way, the KDE developers can now focus on the planned KDE improvements. Read the full announcement here, or go straight to the source (alternative link)."

Comments

The planned features list

[Henry V .009]

The planned features list seems a little unambitious to me. I know that many of the programmers working on KDE are top-notch, but there needs to be some other talent in there as well. In my opinion the KDE developers need to be concentrating on productivity features. They have the opportunity to be at the forefront of that kind of thing. Microsoft wastes plenty of money in researching that kind of thing, but they lack the flexibility to be cutting edge.

Re:The planned features list

[Anonymous Coward]

There won't be huge changes because this is only a small improvement. The reason it makes such a large version jump is stay with Qt. Otherwise it would be called 2.3.

Re:The planned features list

[Henry V .009]

Yeah, I suppose so. I'll have to try developing a couple applications for it to see what it's like.

Re:The planned features list

[Spy Hunter]

Remember, KDE 3.0 is mostly just a port, with the same amount of new features you might expect going from, say 2.2 to 2.3. It is *nothing* at all like the nearly complete rewrite going from KDE 1 to KDE 2.

That said, I expect that there will be far more new features in KDE 3.0 than what's described on that page. Most likely the developers just haven't bothered to tell anyone about all the new features they're going to add yet.

And with KDE's blazing release schedule, 3.1 will be upon us before we know it, with all sorts of goodies :-)

Re:The planned features list

[Arandir]

KDE is a *desktop*, not a productivity suite. Microsoft may be attempting to add everything but the kitchen sink into their desktop, but that's not the way we do things in Unix land.

In my never humble opinion, keep KDE a desktop and infrastructure, and spin off the extra stuff into their own projects (like they did with KOffice).

Re:The planned features list

[jilles]

By definition, infrastructure should encapsulate every feature that is common to the applications that use it. The problem with UNIX is that such infrastructure is lacking. This has lead to a situation where in order to be able to compete with ms windows (which does have such infrastructure), applications have to include everything and the kitchen sink. Look at star office, it comes with its own widgets, its own printing subsystem, its own way of embedding components and until the recent beta it even came with its own desktop. Sure it is integrated with Gnome/KDE to some extent but since it also needs to be portable across the two it contains a lot of duplicated functionality.

KDE developers have understood this and are currently working to deliver such an infrastructure. Ignorant critics complain about konquerors ability to be both a browser and a file manager. However, once you understand what infrastructure is supposed to be you recognize that same ability as a good working infrastructure. File managers and browsers have a lot in common and therefore you might as well integrate them so that you don't have to invent the light twice.

The UNIX philosophy is to make something small and only once. Most unix applications only meet the first part of that philosophy and have to duplicate everything and the kitchensink because it is either not present in the infrastructure or not consistent enough to allow for easy integration (this should also be facilitated by the infrastructure).

Re:The planned features list

[be-fan]

Seems to be a rather developer-oriented project. The cynical among us would question the priority of moving to Qt3 with regard to the fact that TrollTech employs key developers.
>>>>>>
Actually, there is nothing to be cynical about. Qt3 is a big step up from Qt2. For example, it is finally thread-safe. Qt2 was also, in theory, but threading features were unused in KDE programs because of the immaturity of Qt's thread saftey. Check out the Qt3 features list.

Re:The planned features list

[Arandir]

For example, commenting about their kitchen sink tactics, even while admitting that KDE has become a kitchen sink in in the very next sentence.

I didn't say KDE had the kitchen sink included, but I will cede the point. What I am arguing is that it *shouldn't* have the kitchen sink.

Not every KDE application needs to be a part of the core KDE. Keeping KOffice as its own project is a Good Thing(tm). Other ideas of that magnitude should be separate projects as well.

have you tried it mike?

[quannump]

from the as-unstable-as-windows dept.
pff ... i bet it's stabler than slashcode

Re:have you tried it mike?

[JollyTX]

I was very dissappointed with the beta releases of KDE 2.0 (slow, crashed all the time); impressed with KDE 2.1 (a bit faster, more stable) , and I'm mad about 2.2 (fast, extremely stable) ! It's stable, it has tons of features I miss in Win* and I just love it.

Re:have you tried it mike?

[infiniti99]

Actually I think he meant the 3.0 Alpha was probably unstable, not KDE in general. :P

Are there no new speed enhancements...

[nusuth]

Or did they just not made into press release? Kde 2.2.1 rocks but a bit more speed & responsiveness would be nice. I hope kde guys can achive something like the speed change from 2.1 to 2.2.1.

Re:Are there no new speed enhancements...

[Spy Hunter]

I think you just missed them. Look in the planned features list:

icon server, Waldo Bastian bastian@kde.org
KIO/KHTML: pipelined HTTP requests, infrastructure, Waldo Bastian bastian@kde.org

I think the icon server in particular will help with startup times of KDE apps. The pipelined HTTP requests will make loading of webpages faster.

In addition, a lot of the speed problems actually lie with GCC and the GNU linker, which KDE can't help with. The GCC and ld developers have been made aware of the problem, and a lot of work is going on on their end to speed up the dynamic linking of C++ programs. Once these optimizations start making it into stable releases of the linker, KDE will be much more responsive.

Re:Are there no new speed enhancements...

[nusuth]

I don't know what an icon server is, that is why I "missed" :) Is it technically possible to prelink some commonly used programs using idle time? the first application start after kde start seq. would suffer but on average it may pay.

Re:Are there no new speed enhancements...

[Spy Hunter]

I'm not familiar with exactly how the linker enhancements work, but I think they do something like you describe.

About the icon server: Currently each KDE program that wants an icon (every one) goes and checks each directory where that icon might be found (of which there are a lot, KDE has a very customizable icon system). The icon server would catalog all the icons available on startup and serve them to the programs that need them whenever they ask, preventing a lot of disk reads. I think that's the basic idea.

Re:Are there no new speed enhancements...

[debrain]

Yes, a pre-linker is what is being done with GCC. You might notice that kdeinit may run everything in KDE, from konqueror through konsole; that's because kdeinit is already linked. This is annoying when looking at the actual processes running. They're all kdeinit. Especially annoying for killing those zombieish konqueror sessions.

The pre-linking relies on the fact that once libraries are loaded, they never move in memory. That could be a false assumption, but the gcc team is going to great ends to make sure it isn't. The issue as demonstrated is that 'helloworld' will be much larger, and much slower to load when it links against the QT libraries (or any large set of libraries). Thus, similar performance is lost when starting KDE applications linked against the QT libraries simply because they are all loading the QT library linkages.

Re:Are there no new speed enhancements...

[debrain]

Xkill doesn't kill the process owner; you will also notice that a zombied konqueror session will start up again the next time you start KDE. A problem with kdekillall is also that one generally doesn't want to kill everything, only selective unresponsive processes.

It would be nice if xkill did kill the window owner's process, but with Konq, for example, it does not appear to.

Re:Are there no new speed enhancements...

[be-fan]

KDE-2.2 seems to have made the startup thing a little better, but what really still bothers me is widget-drawing speed. Try this little experiement. Start up Word 97 (or 2000, don't know about XP). Resize it as fast as you can. Even on a low-end machine, it will keep up with out. The widgets will move to their proper places and the worst effect will be a little (faint) flicker. Now try the same thing With KWord. When resizing to make the window smaller, there is a visible delay in the toolbars moving to their new positions. When resizing to make the window larger, there is a visible grey area in the just-resized portion before the widgets draw in. For someone who spends a lot of time futzing with windows (me) the effect is really annoying.

Re:Are there no new speed enhancements...

[be-fan]

X doesn't seem to be the bottleneck since I have seen fast X apps. Qt also doesn't seem to be the bottleneck, since Qt apps run quite quickly on Windows. Try downloading the Qt "Theme" example program. It resizes beautifully, even though it has a lot of widgets on screen.

Doesn't data aware widgets break the mvc paradigm?

[caseih]

Just curious. It seems to me that data aware widgets ties the view in too closely with the model and breaks the paradigm. Of course, MVC does have weaknesses, but it seems to be the driving paradigm of graphical user interfaces these days.

Qt is 9/10ths commercial

[mangu]

They NEED large version number jumps.

But I wish they would start releasing two different product lines: "commercial" and "geek".

Re:Qt is 9/10ths commercial

[jonathan_ingram]

No, Qt have never artifically inflated their version number. The first number changes with major binary incompatible changes to the library, the second with additional features that keep binary compatibility, and the third with bug-fixes. KDE uses this numbering scheme as well.

Just because you might be used to other projects (such as the Linux kernel) completely changing interfaces within minor version revisions, doesn't mean that is how a properly managed piece of software is versioned.

kpf - web server applet: please don't

[knarf]

Uh-Oh,

From the planned feature list:

* kpf - web server applet, designed for sharing files

That does not sound like a wise thing to do, implementing webserver functionality into a desktop applet. That's what we've got daemons for, right? Small, self-contained, functional and modular. With the added bonus that the webserver keeps on running when the user logs out.

If you really want to share some files on your box through the desktop, there's lots of P2P apps/'platforms' out there which make this possible. Jabber comes to mind, or JXTA, or... even a 'personal Apache controller applet' for all I care.
But a webserver *in* the applet... Nein Danke...

Re: kpf - web server applet: please don't

[Spy Hunter]

It sounds like a fine thing to do, to me. Why would a user want their files shared while they were logged out? KDE is meant for desktop systems, not file-servers. Most users turn off their computer while they're not logged in. I like the idea of an easy-to-use filesharing mechanism that works over the Internet integrated with the desktop, it is something MS hasn't done yet but is really logical.

Re: kpf - web server applet: please don't

[mindstrm]

Well.. I beg to differ.
If you are speaking of the average techie.. sure, go use another piece of software.

To a windows convert, being able to select a file/folder and hit 'share' would be great.

Re: kpf - web server applet: please don't

[knarf]

It is not the functionality (sharing files) which I dispute, but the place where it is to be implemented (in a desktop applet, as far as I can tell from the TODO-list). From a security standpoint it does not seem to be the best place to implement this functionality. KDE is huge, and has - as far as I know - not been subject of a rigorous check for the usual security-related problems (buffer overflows, etc). This webserver applet would use the KDE framework to serve files to the outside, so it would have to sit there listening on some TCP port. Now what if (and that's probably not an 'if' at all...) there's some exploitable problem in one of the libraries? And this applet is installed on all those KDE desktops which are popping up everywhere thanks to the huge success of free software and the downfall of the evil empire and such?

We'd have the same problems as 'they' have today.

Oh, and for those of you who think I'm disparaging KDE, that's not the case. Replace 'KDE' with 'GNOME' or 'CDE' or 'XFCE' or whichever big(gish) desktop environment you care to name, the same would hold true.

Re: kpf - web server applet: please don't

[knarf]

Uh... If those files the user shares are 'important' to collegues/friends/whoever, why would they only want to share them while logged in? Also, in many workplaces workstations are shared between many people, or used by many people ('flexible office' and such...), so the mere fact that the user is not logged in on a certain machine does not mean she does not want/need to share those files.

The filesharing functionality in itself can be handy, but the place to implement this is not in a desktop applet. A controller for the 'server', sure, put that in an applet. But the server itself is better implemented as a small, self-contained daemon. This makes it much easier to audit it for security problems, and actually fix those problems.

Re: kpf - web server applet: please don't

[SuiteSisterMary]

So Microsoft throws in IIS, and it's a huge security hole. KDE does it, and it's a 'fine thing to do.'

Re: kpf - web server applet: please don't

[Libor Vanek]

That's something COMPLETELY different! IIS is intented to be MS "flagship" as the Internet server. File sharing is (probably) intented to be easy to use for BFU's which just wants to share files simply.

This I think is really great and can help to spread Linux and KDE between more users. Another thing would be if this option will be by default on and will have security troubles.

Re: kpf - web server applet: please don't

[znu]

Mac OS X has a web sharing feature, but it simply fires up Apache (with some nice reasonable defaults). That's probably the best approach.

Re: kpf - web server applet: please don't

[Anonymous Coward]

I'm the author of kpf.

It's not supposed to be a fully-fledged webserver. As the comment says, it's designed for sharing files (e.g. with people you are chatting to on IRC.) It just happens to speak HTTP, because firstly that makes it easy to grab files (kfmclient copy http://some.server/some.file file:/tmp/, or wget if you fancy) and the HTTP protocol is a lot simpler to implement than e.g. FTP.

Simplicity of implementation was a major factor in choosing a protocol because kpf must be secure. The less code, the easier to audit.

Note also that the 'real' web servers are not easy to monitor and control in realtime. Because kpf runs as a panel applet, you can watch the connections and the traffic, and even kill off connections if you don't like what they're doing.

You would be surprised how much traffic kpf can handle without threads, subprocesses, etc. - and running within the same process as kicker - all without slowing down kicker.

The home page is here if you'd like to take a look at the current version (which is for KDE 2.x)

Rik

Re: kpf - web server applet: please don't

[SuiteSisterMary]

That's something COMPLETELY different!

Thanks for making my point so succintly.

Re: kpf - web server applet: please don't

[rikkus-x]

So now I have a slashdot user id. I didn't want one, but
perhaps this will mean I get to respond to ignorant posts
about my software. See parent.

Rik

Re: kpf - web server applet: please don't

[John Allsup]

Whats needed is a better internet infrastructure in the underlying operating system. There is currently nowhere an app can simply say 'share this with these permissions, etc. etc.' and have the requested data immediately available.

Let's face it. At current, we're barely at the point of dynamically configurable webservers. What is needed is a single, uniform way of informing the system of network related requests and letting it carry them out.

In pseudocode, one should be able to say

network.shareDirectory(
Directory => "$HOME/export/hello",
Protocol => SMB,
ShareName => "hello/world"
)

to make the directory '$HOME/export/hello' available
at '\\MyComputer\hello\world'

OR


network.shareDirectory(
Directory => "$HOME/export/hello",
Protocol => HTTP,
ShareName => "hello/world"
)

to make it available at 'http://MyComputer/hello/world' etc.

Obviously extra stuff needs to be given at runtime, but you get the idea. This is something that needs to be given serious thought. What can be done? (the reasoning behind this should be obvious: you shouldn't have to learn everything over again when moving from, say, apache to Roxen to wuftpd to samba to whatever next...)

Re: kpf - web server applet: please don't

[platypus]

Hi Rik,

do you plan to implement webdav and do you know if there's a corresponding client for kde? Can konqui handle it?

Re: kpf - web server applet: please don't

[rikkus-x]

No, sorry, kpf is read-only for security.

I don't have the time or enough experience to
allow writing - that would require much more code
and much more auditing.

I think I heard of a kio_webdav, but I don't know
if it ever saw light. Check google :)

Rik

Re: kpf - web server applet: please don't

[rikkus-x]

Let's face it. At current, we're barely at the point of dynamically configurable webservers. What is needed is a single, uniform way of informing the system of network related requests and letting it carry them out.

How's this ?

dcop kpf createServer /some/export 8080 4000 10 false

That creates a new server serving files from /some/export, listening on port 8080, with a 4k/s bandwidth limit, a limit of 10 concurrent clients, and disallowing following of symbolic links.

There are other useful DCOP calls you can make too, here's the rest of them: disableServer, restartServer, reconfigureServer, pauseServer, unpauseServer, serverPaused.

Of course, you can do all these things with the applet's config dialog or by right-clicking on one of the server graphs. You can also play with the settings by using the directory properties dialog in konqy, which has an extra tab when you install kpf (only in 0.4.2, the unstable version, currently.)

Rik

Re: kpf - web server applet: please don't

[rikkus-x]

The KDE libraries are by design quite safe. You don't have the buffer overflow problems that you have in C. Please, if you would like to allege that my code is compromisable, have a look at the last stable release (0.4) of kpf and see if you can tell me where. Until you can prove that kpf is insecure, you are merely spreading FUD. Rik

Re: kpf - web server applet: please don't

[rikkus-x]

Why should daemons not be tied to GUIs ?

Apart from the obvious - they stop when you
log out. But this is a file sharing utility,
not a CGI-running multiple-process-spawning
web server.

Rik

Re: kpf - web server applet: please don't

[Vann_v2]

Yeah, it does make your point if you ignore his justifications.

Re: kpf - web server applet: please don't

[SuiteSisterMary]

Exactly; on Linux, it's 'justified' to have a web server running for no good reason. On Microsoft it's 'inexcusable' and 'stupid.' Want to share files on UNIX? NFS. Samba. FTP. Want to do it automatically? Then screw Morpheous, I'll just troll the @home subnets for open kpf shares.

Why offtopic?

[mangu]

At the time I post this, the parent is moderated (-1, offtopic).

WHY?

It's about KDE. Absolutely ON topic...

I post this using my own nick because I'm stuck at +50 and need someone to mod me down...

Re:GNOME _is_ obsolete

[jonathan_ingram]

I think you're running the risk of turning from one sort of fanatic to another.

When KDE was in transition from 1.1 to 2.0, a lot of people assumes that there was very little work going on, when in fact (as we now know) they were almost completely rewriting the core libraries. A similar thing is happening with Gnome -- and it's very hard to show people what you are doing until the main libraries are 90% complete. So lets give the Gnome guys a chance and see what they produce.

(the only thing I'm waiting for to make me happy is for Lyx 1.2 to come out so I can finally get rid of that xforms library...)

Re:Time to drop Gnome?

[hexix]

Seems to me the reason you are seeing these projects moving so fast is because there are two. In fact if you just look at the planned features for KDE 3.0 a lot of them are the same as the planned features for GNOME 2.0 (bi-directional language support for example).

I doubt having them both is hurting anything, people developing for GNOME probably are wanting something else out of a desktop than KDE and vice versa. So I doubt that killing one project would mean all those developers would jump ships.

I think instead we should be trying to make the fact that two desktops exist just a trivial thing. Make them share stuff like application menus, desktops, etc. Another thing I'd really like to see is a common theme format, so the programs would look alike, although I doubt we'll ever see that.

hardware-accelerated alpha blending?!

[Adnans]

"and hardware-accelerated alpha blending"

buzzword or actually implemented in the new KDE/Qt? Alpha blending IMHO increases elegance (not to be confused with usability) of an interface when used properly. Any KDE developer(s) care to explain how and what this actually means? e.g. Render calls, which components use this, etc?

Thanks,
-adnans

Re:hardware-accelerated alpha blending?!

[Spy Hunter]

The new QT has support for alpha-blending through the X Render extension. This means:

Better (full) PNG transparency support in the browser
Alpha-blending for all icons everywhere to reduce jagged edges (especially for small icons)
Neat eyecandy effects

What I'm interested in is what happens when Render isn't available? Do all those effects go away cleanly, or do they stay there using slow software emulation?

Re:hardware-accelerated alpha blending?!

[mabinogi]

Probably not.....if the way I understand it is correct, then the Render extension just provides a way to get hardware accelerated alpha blending.

To optain a truely transparent terminal, when an area of desktop, or a window changed it's contents, X would have to repaint all the windows above that area or window, which previously would have been something that X deliberately would not have done (since it would have been pointless).

I don't think that the render extension changes anything fundamental about X, just provides an extension that applications can use to speed up certain things.

Though I could be wrong, since I have not really read much about it.

Re:hardware-accelerated alpha blending?!

[hexix]

I think it actually is possible with the render extension. If you check out keith packard's page that tells about it he has a screenshot of a hacked FVWM where the menus are translucent. check it out here.

Of course maybe it isn't possible, I would have thought the Eterm developers or someone would have made a terminal program to use this ability already.

Re:hardware-accelerated alpha blending?!

[JabberWokky]

Does that mean it could be possible to have a truely transparent terminal?

Yup - see the bottom of this page. Now, I *am* curious as to how fast this is in a real world system. And knowing how KDE works right now, it will porobably be easy to turn on and off (like current font and icon antialiasing), both explictly, and in a warm, fuzzy "Quality slider".

--
Evan

intrested in C bindings

[johnjones]

they state that they will have C bindings

well that's new I wonder if they are going to anything like GTK C bindings ?

and I think that a web server applet is a bad idea
(although implemeting a control function for apache DAV would be good)

and the really good news is
Remapping/Naming of Modifier Keys: emulation of traditional Mac keyboard, where Ctrl is called "Command", Meta "Alt", and Alt "Apple", and "Apple" has the function of Ctrl. Let Meta be called "Win" for MS Windows users. Let a user without a Meta key easily select another modifier (e.g. CTRL_R) to act as Meta.

that is a blessing, I hope that others follow the example and provide an alternitive mapping
(RISCOS had it like this and I got on well with it, same as the mac I use)

regards

john jones

Re:intrested in C bindings

[Arandir]

Please, oh please, don't call the meta key "Win"! Just because my keyboard has three keys with funny symbols on them, don't assume that I am a MS Windows users. I mean really! If I were a Windows user, I wouldn't be using KDE now, would I!

There should be an explanation somewhere that the key on most PC keyboards with the MS logo is the "alt" key. That goes without saying. But don't rename it!

Re:intrested in C bindings

[Arandir]

I'll dispute the label of "fucktard", but I will admit to needing a WYMIWYT(*) interface to Slashdot.

(*) "What You Mean is What You Type"

Gnome User

[Picass0]

I'm currious from anyone who has used Gnome and switched to KDE: what do you think the advantages are? I'm open minded enough to consider KDE, but want to know what people feel is better. (Please be more specific than Gnome sucks. That's not going to sway me very much.)

Also, anyone reading this who has left KDE for Gnome tell me what made you switch.

I've always thought this Gnome vs. KDE thing was about as dumb as vi vs. emacs.

Re:Gnome User

[reverius]

I switched from KDE to Gnome. The primary reason was an easy one... the latest GNOME is available (through Ximian) for Debian Stable (aka Potato, aka 2.2)... but the latest KDE is a bit harder to do.

When I tried KDE 2.1 on this box, it seemed kinda sluggish. KDE 2.2 is a lot faster, but it ain't gonna run on Debian 2.2.

A big plus for me as well is the customizability (albeit mostly hidden) of gnome. I can completely remove the desktop icons (and Nautilus itself ;)) and save on system resources. I can make my whole user interface look exactly like MacOS 8 (which I do). So I use Gnome instead of KDE.

If Debian 2.3 (Woody) would come out soon, I'd be glad to try KDE 2.2 on it, and maybe stick with it. :)

Re:Gnome User

[slashdot2.2sucks]

I don't use either Gnome or KDE, because I like just a nice WM like E or WindowMaker so I feel my opinion is probably not very biased.

After Gnome became stable (1.X) I tried both Gnome and KDE and found that KDE was like vanilla MacOS and seemed to lack the amount of neat features that Gnome had. But I still didn't use Gnome because it was too slow on my machine.

I just recently used both and I have to say that I think the roles have reversed. The newest KDE is very sexy with good use of anti-aliasing and alpha. KDE seems to have gone the OSX route but with a more mature look.

I would say that I think the latest KDE is even better than OSX, but I am biased in that I think that the Aqua theme is ass candy fugly.

Re:Gnome User

[jonathan_ingram]

Back when it was KDE 1 vs Gnome 1.2, I used Gnome... or bits of it. For ages I used Sawfish on its own, back when it was called Sawmill and wasn't the Gnome default window manager. I always hated GMC, and didn't use the panel much... so my use of Gnome was mostly restricted to the applications, and most of those (Gimp, XChat, ...) were GTK+ rather than Gnome.

Once KDE 2 came out, I found myself using Konqueror more and more, plus Konsole, mostly because of the tabbed MDI interface it has (which is wonderful). From there it was a small step to actually running the whole KDE desktop -- I even got used to the KDE window manager, although it still feels a bit clunky in comparison to Sawfish (I see that KDE 3 will have active desktop borders back again though, which is wonderful).

Of course, I can still run all the same GTK+ applications I used to use, and they work just as well. Kate, Konsole and Konqueror are the killer apps for KDE, plus the way it all feels much more integrated together than Gnome does (although it has the better individual applications).

I've always thought this Gnome vs. KDE thing was about as dumb as vi vs. emacs.

And it'll keep on going just as long as vi vs. emacs...

Re:Gnome User

[nusuth]

I prefer KDE but I'm not really a convert. I installed both for a time until I decided KDE was better and I had no use for gnome. As for why I think KDE is better, I can't really give concrete reasons. The looks are worse, localization is better, customizability is a bit better, default terminal is better, default browser is better, rpm manager is worse...but no real big differences between the two. I'll install KDE at work for the simple reason that its office suit and desktop can be configured to look quite like windows, to which folks at my company are used to.

Re:Gnome User

[hexix]

Well I use both, usually GNOME more often as I like the look I can achieve with it and pretty much all my favorite programs are gtk+ based, so it's nice having the same look for everything.

But the reason I think a lot of people like KDE is because of the level of integration everything has. It truly is a Desktop Environment, whereas GNOME at this point has more of a "most of the programs look similar" feel to it. Very little seems to be in place for the programs to talk to eachother and work the same from application to application.

For example, in KDE2 every program that opens files (to the best of my knowledge) uses KIO (I'm guessing that stands for KDE Input Outout) and this makes it so you can open and save files from/to anything KIO supports. For example, you can open a file in a KDE text editing program by giving a http url like http://slashdot.org/ (that should give you the source code for slashdot's main page in HTML) then you could then save that file to some ftp site, just by putting ftp://blah.com/incoming/file.html in the save dialog.

That level of integration is all over KDE2 and it really makes for a great experience. There is tons of other stuff too, like how konqueror embeds components so it can display many types of files. In fact, if I'm not wrong, the koffice office suite is made up of components so I think you can view kword files in konqueror without really launching the kword application, just embeds it into konqueror's window.

Lots of other stuff to explore in KDE. For me though I just like the look and feel of GNOME. And I think all those nifty things in KDE give it a lot more stuff that can break (and from my experience it tends to do just that). Of course I could just have bad luck with it, I dunno.

Re:Gnome User

[fault0]

What I've used:

KDE 1.0 vs. Nothing: KDE 1.0
KDE 1.1 vs. Nothing: KDE 1.0
KDE 1.2 vs. GNOME 1.0: KDE 1.2
KDE 1.2 vs. GNOME 1.2: GNOME 1.2
KDE 2.0 vs. GNOME 1.2: both (but more GNOME 1.2)
KDE 2.1 vs. GNOME 1.2: KDE 2.1
KDE 2.2 vs. GNOME 1.4: KDE 2.2
KDE 3.0 vs. GNOME 2.0: I probably will use KDE 3.0

Frankly speaking, both DE's are good, but I like KDE better since 2.0. Right now, I prefer KDE a lot more than GNOME. It's more mature, more stable, and has more features that I want and need. The only downside I can think of with KDE was the lack of eye candy and customizability. But, KDE 2.1 and KDE 2.2 really seemed to fill in the gap. KDE 2.2's panel is about as customizable as GNOME 1.4's panel. The theme support is about the same (although there is nothing like the KDE Liquid theme, with transparent menus, shadowed text, and strippled window backgrounds for GNOME). I think that the rest of the "look" aspect is better for KDE. It has builtin antialiasing (gdkxft for GNOME doesn't work for everything). I also like the alpha transparent icons in KDE. I think KDE 3.0 will really shine because of the builtin xrender support in Qt. This should allow stuff like truly transparent terminals and windows :).

KDE also seems to be faster in some areas (Konq. vs. Nautilus, for example). Most of the rest of speed is about the same (provided kde uses objprelink). Application support is about the same.

I think that the biggest thing going for KDE is probably that it is a lot more intregrated than GNOME is. I think that that's what a "desktop environment" should be, after all.

Re:Gnome User

[jfunk]

Don't forget the coolest feature of KDE file dialogs: bookmarks.

The GNOME file dialog is a royal pain to use. It's ugly (layout and widgets) and has no useablity features. I find myself frustrated whenever I use it.

Re:Gnome User

[Anonymous Coward]

I'm one of the many who went from GNOME to KDE -- but in my case it's because I spent the last three years coding for BeOS, which had a wonderful c++ api. Just beautiful.
When I realized I had to bail to another OS(choosing linux, obviously) I went to GNOME, since all the screenshots looked so damn purdy.

But I spent, perhaps, 2 weeks *attempting* to make GTK+ cede to my will, without any worthwhile success.

For reference, I'm not a c++-only kinda guy. I used to work at a software company writing device drivers for early set-top-boxes in assembler and c. So I _do_ know that kind of stuff. Quite well, in fact.

The trouble was... GTK+ just didn't make any *sense* to me!

And on the other hand, QT _did_ and KDE is, after all, written not just in QT/C++, but it follows the same naming and logical conventions (which are, I might add, well thought out.)

In the end, I actually prefered using GNOME. I think it's nice and slick, and has good minimalist approaches to the user experience. Relative to KDE it's quite minimalist. By this point (6 months into linux use/programming) I've managed to learn KDE well enough that it's a good experience for me...

but by god I'm never going to touch GTK/GNOME APIs again if I don't have to.

Just my 2c

Re:Gnome User

[hexix]

It's stupid cause why do you care what other people use? It's fine to like a program but what's the point of trying to push it on other people? Especially a text editor, as a text file will work with any text editor. I'd say that makes it a pretty stupid debate.

Re:Gnome User

[Xiphoid Process]

"The GNOME file dialog is a royal pain to use. It's ugly (layout and widgets) and has no useablity features. I find myself frustrated whenever I use it. "

Which is why it has been rewritten for Gnome 2.0 :)

Re:Gnome User

[jonathan_ingram]

Your desktop environment timeline is very similar to mine :)

although there is nothing like the KDE Liquid theme, with transparent menus, shadowed text, and strippled window backgrounds

I really wish Mosfet hadn't had that stupid little spat with the core KDE developers -- KDE needs people like him who are interested in both graphics and programming. He just seemed to have a habit of checking code in 2 days after the final code-freeze deadlines...

(for those of you new to the story -- Mosfet developed the KDE 2 style engines as well as Pixie. After being told that he couldn't add his Liquid style because it was after a feature freeze deadline, Mosfet decided to remove all his code from the KDE CVS and change the license on it to a form of the QPL. Most of the styles have been readded in the form they were before they were removed, and are now being developed independently. This is a picture of Liquid, which is nice I suppose if you like that sort of thing.)

Re:Gnome User

[hexix]

Yeah definitely. I'm pretty sure that GNOME is getting a new file selection dialog, in fact in Ximian GNOME right now there is a new one, which is much nicer.

My only gripe about the KDE file selection dialog is the fact that you can't specify directories in the same spot you type in files. One thing I've grown to love about the Gnome/GTK+ file selection dialog (no matter how ugly it is) is that I can use tab completion to specify a full path very quickly, just like in a bash shell. For example, if I want to get to the directory /usr/share/pixmaps/backgrounds I can type /usr/shpixba and that will usually get me there very quickly. And you can do the same thing with files of course, and if there is more then one match when you hit tab, that's what files/directories the file selection dialog will show so you can find files very quickly this way.

With KDE's there is a seperate text input for the directory, which is nice and it should stay that way but I think they should add the ability to specify the directory in the file text input box.

But, pretty small gripe considering all the things the GNOME/GTK+ selection dialog has wrong with it ;)

Re:Gnome User

[Anonymous Coward]

kwin is fully scriptable. It has a full dcop interface. And so does almost every KDE application. And you don't even need to know lisp, since you can intregrate it with __any__ language, as well as shell scripts (through the dcop command). Kwin can also be styled and theme much more than sawfish because of kwin's engine theme support, written in C++. For example, you could embed a khtml widget in the titlebar to display a webpage. Lets see crazy stuff like that with sawfish :). Since kwin's engines are in C++, kwin also happens to consume a lot fewer resources because it does not use a much slower lisp interpreter like sawfish.

if still like sawfish, you can use it with > KDE 2.0. sawfish is fully compatible with the NETWM spec which GNOME 1.4 has recently adopted and KDE has since 2.0. I've used sawfish in the past too, but I gotta say that kwin simply r0x0rs.

Re:Gnome User

[pivo]

Let me get this striaght. You think that national policy and what someone (whom you don't even know) should use for a text editor are equally valid debates?

Re:Gnome User

[FunkyChild]

I can make my whole user interface look exactly like MacOS 8 (which I do).

With a working mac-style menu bar like KDE does, eh? ;)

Re:Gnome User

[tzanger]

My only gripe about the KDE file selection dialog is the fact that you can't specify directories in the same spot you type in files.

Uh... I just tested this with KATE. Alt-f, o, win/autoexec.bat [enter] -- works just fine. Same with saving.

Now I don't have the nifty tab completion but if I type the directory in the directory text entry widget I can do /usr/sh[end]/pix[end] and then tab down to the file...

Re:Gnome User

[hexix]

I meant you can't switch to a different directory without going and typing it in in the other field. with GTK+'s you can type the directory name and hit tab and it will show the contents of that directory. No need to switch to the other text field and type in the directory then switch back to the other text field. That's all I was trying to say.

Re:Gnome User

[Nailer]

I'm pretty sure that GNOME is getting a new file selection dialog, in fact in Ximian GNOME right now there is a new one, which is much nicer.

Even more interesting: this is actually a complete remake of the file selection from Microsoft Office 2000.

Re:Gnome User

[hagbard5235]

I've recently switched from Enlightenment/Gnome
as a desktop to KDE. Two major driving
factors where Konqueror and Konsole ( tabbed
shells... mmm... ). I had previously
used Galeon, and I prefer Konqueror in most
respects ( but please for the love of God bring
tabbed browsing to Konqueror!! ).

I still use Evolution for email
( kmail is just not as feature rich or usable )
and Gnumeric for spreadsheets. I would say that
Kmail and Kspread still need a fair bit more work
to catch up (particularily kmail).

Re:Gnome User

[puetzk]

but you can... just type in the dir name and hit return, and there you are.

No tabcompleting the names though (unless you use the other field). I admit that. It would be a small, nice feature for kde3 to add, now that you mention it. Maybe I'll file a wishlist on that, or even just write it myself :-)

Re:Gnome User

[Ranger Rick]

Same here. Tabbed shells is so freakin' awesome, I have no idea how they didn't exist before. It's great being able to work on something and change the tabs to match the host or system or program I'm working with in that window...

That's what switched me; 90% of my work is either browsing or working in a shell. KDE excels at that...

Re:Gnome User

[Ranger Rick]

Follows my timeline too... I've recently been loving the extra effective screen space I get out of AA font support in *every* QT app already being available. Along with mosfet, I've got a desktop that's both beautiful and (gasp!) useful... (screenshot).

Re:Gnome User

[foonf]

I started using GNOME around 1.0. I picked it because of the eye candy -- it crashed more often and was slower than KDE 1.1, but both were slow enough and crashed enough on my Cyrix 6x86 that I wasn't too concerned with that.

I was really impressed with GNOME 1.2. Along with improvements to enlightenment (I kept using it even after Sawfish became the default -- it is "small and light" only compared to E, and it lacks all the eye candy), it became quite stable and customizable.

1.4 was not a major improvement. I couldn't ever get Nautilus to work on Red Hat 6.x, which I was still using (thanks to Ximian's excellent update system). And gmc was going nowhere. And other than Nautilus little else was changed about 1.4. At the same time, KDE 2 was improving rapidly. I installed the core components of 2.1 in order to use Konqueror as browser, and was quite impressed with the overall feel of it.

When I finally decided to install a new distro (Slackware 8) I went with KDE 2, mainly to get a feel for it. I didn't really look back...of course, it didn't help that I couldn't get the default gnome installation to run Nautilus on startup (even when you can get it to work, it doesn't feel very well integrated with the rest of the desktop). But although I use it, and like it, I really dispute the argument that it has totally supplanted GNOME, and GNOME has no longer any purpose.

Because I basically use KDE as a front end to GNOME and GTK applications. Its true that a few -- XChat, GIMP, GFTP and Abiword -- do not require GNOME, others -- Galeon, Evolution, Pan,to name a few, are completely dependent on GNOME. And visually KDE is still behind, and it doesn't quite have the themability that E/GNOME did. It seems like all the ugly E, Sawmill and GTK themes have been ported to KDE, but I still can't make it look like this.

And no (referring to screenshot), that useful XMMS panel control has no KDE equivalent. Neither does mini-commander, the box next to the clock for entering commands. And that system monitor? Thats Gkrellm, it uses GTK. I hope GNOME 2.0 is much improved...as you can tell, I would like to use it again.

Re:Gnome User

[root_42]

> and it doesn't quite have the themability that
> E/GNOME did.

That's not true anymore. Try High Performance Liquid for example. Ok, KDE needs more of these themes, but I for once like the plain themes/styles, because eye candy things are really bad for daily work.

> that useful XMMS panel control has no KDE
> equivalent.

Well, it doesn't have to! Just take wmxmms from WindoMaker and load the Dock Application Bar Extension for Kicker (the Panel). Then you can use ALL of you favourite WM dock apps.

> Neither does mini-commander, the box next to
> the clock for entering commands.

I like the Alt-F2 command box from KDE better. No need to take your hands from the keyboard. Plus you can execute su-commands with it.

> And that system monitor? Thats Gkrellm, it
> uses GTK.

Well, granted. There's no spiffy Gkrellm for KDE, but hey! KDE does run GTK apps, too, doesn't it?

Re:Gnome User

[Jens]

One thing I've grown to love about the Gnome/GTK+ file selection dialog (no matter how ugly it is) is that I can use tab completion to specify a full path very quickly

Have you ever right-clicked on the file name input widget? It says right there: "Completion: (none, manual, menu, automatic, short automatic)"

This goes for EVERY input widget that accepts URLs. Not only for file dialogs. KDE rocks. :-)

Re:Gnome User

[Error27]

Actually, the only proplem I have with the Gnome file dialogue is that there is no way to display hidden files except typing '.' and 'tab.' New users don't know how to do this and experienced users don't want to have to move their hand from the mouse button to the keyboard and back.

In KDE it takes three mouse clicks to show hidden files and three mouse clicks to hide them again. That's as annoying as gnome.

Personally, I think Gnome's way of showing all files regardless of type is better than KDE's and microsofts way of only displaying certain types of files. This may seem usefull at first but it confuses newbies who wonder, "Hey! Who deleted all my files?!?" It is better to allow users to organize their own files into sub directories.

In general, the only hidden files should be hidden files but you should be able to display or hide them again at the click of a button.

(KDE file menu has some other nice features... I think the home button and bookmarks are nice.)

Alpha blending

[hexix]

The release notes mentions hardware accelerated alpha blending. Does this mean that KDE will have a super smooth looking desktop like Nautilus but still be very fast? I love the look of Nautilus when the smooth graphics are turned on, but the performance hit sucks.

Also this should get rid of the sharp edges of icons in the KDE menu and on buttons in programs right? Or are they only using it for fading out inactive items?

Anyone have a screenshot of KDE 3.0 alpha showing how the alpha blending looks?

Re:Alpha blending

[hexix]

I was refering to the smoothing nautilus does to the icons. It blends a drop shadow in with the background. It looks very nice, even has drop shadows that fade into the background. But, like I said before, it comes at a performance hit. So I was wondering, or more like hoping, that KDE 3.0 would give the same great look but do it much faster.

Re:Alpha blending

[fault0]

No, actually almost all cards in XFree 4.1 have xrender support. And so has the closed-src NVIDIA driver for almost 8 months now.

Re:Alpha blending

[fault0]

KDE already does this for all large icons. It has since KDE 2.1.

kcontrol->Icons->blend alpha channel

Currently, it uses software rendering to do it (Konq. seems a lot faster than Nautilus). KDE 3 will use xrender to do it, which will be hardware accelerrated (and so, there will be no performance hit because the video card handles it instead of the CPU).

Re:Alpha blending

[dangermouse]

What would be *really* swank is drop-shadowed windows, a la OS X.

Those shadows and true transparency in Terminal are my favorite pieces of eye candy on that OS.

Re:Alpha blending

[fault0]

both of which is possible with xrender

"Just as unstable as Windows" - Ballmer

[Scoria]

One thing to make this article better:

from the developers-developers-developers dept.

:)

Don't get me wrong but...

[Snoozer_man]

I don't like kde or gnome for that matter, If I wanted a cpu heavy WM I'd use windows. I know saying that will piss some people off but it's true. The reason I started useinglinux a few years ago was to NOT have a computer thats memory was all bogged down with the GUI (windows) so I turned to Linux. WM's like kde and Gnome are great for transition from windows but the reason for changing should be to get more out of your PC not just to be cool or whatever.I usually use XFCE or iceWM mainly because I don't carre what "theme" I'm using, I care about how well my apps will run. Please don't flame me for saying that.

Re:Don't get me wrong but...

[Snoozer_man]

Thats a great reply, I'm realy glad you thought about what you said before you said it! LMAO. ok let me put what I said straight for you GNOME and KDE are not for me. I like to put my cup to use in other areas like getting work done. ok now don't get me wrong I never said they suck actually they are great just NOT FOR ME. ok? I'm sorry if I offended you.

Re:Don't get me wrong but...

[Anonymous Coward]

You don't need to run *all* of KDE *or* GNOME, which is the great thing about both projects.

Take me. When I first ran across GNOME (around 1.0), it was really unstable. However, gnome-panel beat the snot out of AfterStep's wharf. So I just ran the panel, and ignored the rest of GNOME.

Now that GNOME is all around better than before, I actually run gnome-session, and have GNOME start my WM. I still don't use gmc, which I don't like, and stick to bash for file management. No icons on the desktop, but I'm using GNOME and GNOME apps.

So while you certainly don't have to run GNOME or KDE or GNUStep (It's Linux! The land of choice!), be aware that the parts may be worth more than the whole.

This is NOT my home page.

Re:Don't get me wrong but...

[dangermouse]

So, the reason I switched from Windows to Linux full-time is that Windows sucked at its job. (It's gotten a lot better, incidentally, but still doesn't do it for me.)

In terms of "getting more out of" my PC... it's a desktop machine. Its entire purpose in life is to provide me with a decent set of apps in a nice, convenient, featureful interfce. "Getting more" does not involve stripping down the UI to bare minimum so I can encode the occasional vorbis file a little bit faster. That's what nice(1) and renice(8) are for.

Maybe it's just me, but the "just to be cool" factor seems to be more prevalent among people who use Blackbox, Enlightenment, and Windowmaker than among those who use a full Gnome or (especially) KDE desktop.

KDE isn't leet, I'm told. Oh well.

Re:Don't get me wrong but...

[notten]

Umm, KDE2 isn't that resource heavy. Well, OK, maybe it is, but I run KDE2 in FreeBSD and I think it's great. I don't mind the resource usage even if my computer sucks (K6-2 450 / 128 MB SDRAM) because I get lots of stuff I need. Probably the best example I can give you is the Konsole program spread across all desktops with vi running in at least 5 tabs. It's the only way I can code my OS. In most other DEs I'd either have to run multiple console windows or have only 1 desktop. Remember that KDE is not just a Window Manager but an entire Desktop Environment. Maybe you'd change your mind if you tried KDE2. It's bad like KDE1. I actually have to congratulate KDE devs for making KDE2 so good. Hope you change your narrow mind.

notten

Re:Don't get me wrong but...

[Snoozer_man]

Sorry guys I obviously didn't make my point clear (my fault) yes linux needs WM like Gnome and KDE yes they are easy to use, Yes I'm glad they are there to make it easier for people to use, I just don't like them for my WM. I've got a p2 350 (although I do have 400+ MB of ram ;) and my computer runs great with XFCE or a lighter weight WM, It doesn't slow to a crawl with Gnome or KDE but you do see a difference in preformance. KDE is great, so is Gnome, just not my cup of tea.

Re:Doesn't data aware widgets break the mvc paradi

[Arandir]

In OO design, you have the eternal war between cohesion and coupling. High cohesion is good (classes to only one thing). Low coupling is good (classes are independent). But high cohesion leads to high coupling, and vice versa.

MVC is a good design and has a nice balance between cohesion and coupling. Unfortunately, like all good designs, templates and patterns, once you overlay it with a real application it's not so perfect anymore.

Data aware widgets have high coupling. But in turn they get high cohesion. If that level of cohesion is desired (a component, for example), then there's not much you can do about it, MVC or otherwise.

Some Konqueror Updates Would Be Nice

[mfearby]

Konqueror is much better than GMC IMHO, and more configurable than Nautilus, but some updates to the file-browser part of Konqueror would be nice. In particular, something emulating the functionality of Windoze's listview control would be nice. I hate having to view in large icon mode just to draw boxes around files to select them. When in detailed list view, selecting a file selects the whole row when it should ideally only select the filename in the first column.

This might sound petty but this particular aspect when compared with Windoze Explorer makes the Konqueror file browser feel almost like winfile.exe when it comes to selecting files.

Just my 2cents worth. I'm still going to use KDE regardless, though, because Nautilus is slow and has very few options for configuring it.

Re:Some Konqueror Updates Would Be Nice

[Spy Hunter]

I think this has been fixed in 2.2. I know it was fixed for at least one of the kinds of listviews.

Re:Great, just what we needed

[fault0]

> KDE programs are
> very slow to compile
use ./configure --enable-final
this reduces compile times by more than half, in my experience

> and load.
Use objprelink.

> but the point is that KDE is a hell of a lot slower than GNOME.

From what? Load times? Look at other big applications written in C++ and compiled in g++, like Mozilla and OpenOffice. They tend to load slow too. If you actually look at speed of applications, KDE wins hands down. Konqueror versus Nautilus. Konqueror wins. KOffice versus StarOffice/OO, KOffice wins. Other components tend to be around the same speed.

> So, from my perspective, which is not that of a compiler designer, GNOME is a lot freaking faster than KDE.

Yeah, "ordinary users" don't even compile KDE or GNOME.

Re:Flamebait

[fault0]

> http://jimmac.musichall.cz/screenshots/OpenOffice. jpeg

How about KOffice, it is a more pleasant to work with than OpenOffice, and does not take the route of Microsoft's add-features-that-1%-of-the-population-uses way of developing Microsoft Office. Also, it actually features integration with the underlying desktop, unlike OpenOffice.

> add some SVG boys, KDE is starting to look butt-ugly:
> http://jimmac.musichall.cz/screenshots/e-sync.jpeg

KDE already has SVG support in two different implementations. KDE's own and Qt's.

Also, I have yet to see transcluesent menus like in KDE:
http://www.mosfet.org/hpl1.png

KDE -- the desktop that doesn't have to continuously play catchup

Is it that, or they just don't have time...

[Svartalf]

After all, if there's sufficient differences, you're going to end up with two totally different versions of the app's source tree to maintain. I don't know about you, but I don't have that much time on my hands and I suspect that it's the same for them too.

you're right, but use Afterstep

[Penguinoflight]

I've found for usability, Afterstep is the best. Before CmdrTaco had 1.5gigs of ram he used it :-) Afterstep is faster in my testing than blackbox, and it looks better/works better. I just don't like the lack of Afterstep support, but then again usually the elite are few.

Here come the next minor releases of every distro

[dsplat]

A new release of KDE is probably enough to drive new minor releases for a lot of distros. So, what other widely used stuff is seeing a new release these days? The news about the StarOffice beta isn't even cold yet, so I expect we'll be seeing that.

Better desktop, better linux acceptance ...

[ciupman]

We are all geeks, who like to fiddle with bash and read slashdot, and, in my opinion, Kde is becoming the best bridge from windows to linux for those non-geeks, those that still need advanced classes on how to press the start button with the mouse.. Gnome is beautifull but it lacks some integration (at least some that is visible to the eye).. Kde is going in the right direction.

"Use Lzip and find God"

Re:Flamebait

[fault0]

Actually, kword copies a better app than starwriter does. Starwriter copies Microsoft Word, a not-so-versitile program that has thousands of useless features which hardly anyone uses and which contribute to overall bloat. kword copies Adobe Framemaker, a very versitile frame based program that can pass of as either a word processor or a professional desktop publishing program. It has features which 99% of the population needs or could ever want. Comparing kword and starwriter is a bad joke. the only thing that kword lacks is more export filters. with them, it'd be perfect, imho.

Usability?

[Anonymous Coward]

This list doesn't address usability problems in a way that lets the casual reader know if usability issues are being addressed. Its simply not possible from the list, yet as far as developers are conderned this is a very concrete definition of issues for KDE 3. But usability by casual user is probably the only real obstacle between Lunux & KDE and the desktops of of those users who care more about getting their job done than they do whether the desktop was free (as in free beer). GNOME faces the same obstacle. The next version of KDE should be based on usability surveys, such as Sun did with GNOME. Perhaps the KDE developers could get IBM to fund a study?

KDE.

[digitaltraveller]

I am a diehard KDE fan. I used to be a diehard gnome fan, before KDE 2.01. I will probably switch back and forth, as each desktop races ahead of the other. This competition is great, as everyone says. The problem though, and it's a huge problem is for those of us who program for KDE/GNOME. These are not just 2 user-space apps. They are part of the linux desktop infrastructure.

Everyone prefers running programs that are native to their desktop environments toolkit. The problem is that quite often, there is a better program for the other desktop environment. I can't help but think that Linux would be the king of the desktop right now if it wasn't for all this duplicated effort.
I put this question to Slashdotters:

What can we do to resolve this?

Here are a few of my ideas:

-Wrappers for one toolkit's API is translated into the other toolkit's API. I _think_ KDE might already be doing this somewhat. I am not sure of the status.

-A RAD tool, for both desktops. This would be awesome. Look at a great tool like glade. (glade rocks!) Imagine it could generate KDE/QT code as well. Then individual users could "make with-kde" or "make with-gnome".

-Along the same lines, a library that wrapped both toolkits, eg an entirely new API.

Anyone have any other suggestions?

Re:KDE.

[Jagasian]

The main reason for two different APIs is because they are both, most likely, architectured completely differently from each other. One is OO while the other is procedural.

A simple wrapper around one would only lead to a mess similar to Microsoft's MFC, which started out as a wrapper around old procedural windows APIs. Anyone who has used MFC knows the evils of such wrapper APIs.

Re:KDE.

[dwlemon]

I really don't think you need to wrap the entire API or anything. So there are two sets of libraries on a system... big deal. One wonders how many versions of the UI exist on a windows XP box...

the problem with adding a new meta-API is that developers no longer have two choices.. they would have three.

Take a tool like Guppi (graphing utility) that can be plugged into a program and is used in Gnumeric/Gnucash.. If a tool like this could be shared between GNOME and KDE applications, it would do a lot to unify the projects. I guess the way to do this would be to wrap just the component architecture, and I'm assuming one of kparts or bonobo is a superset of the other and a wrap would be possible...

But if not, I'm sure there is a lot that can be done in writing of tools like Guppi that would give them more flexibility in the types of programs that can use it.

Take for instance the icon server which is a new part of KDE 3.0. I don't see why this couldn't be generalized and available for any app to use.. even GNOME apps.

Making one toolkit look like another shouldn't be hard. I know GTK has a bitmap engine, QT probably does too... doesn't QT already load GTK themes?

But the fact is that none of this will happen unless the people who actually write the code (not me) or one of the major distros like Red Hat decide to make it happen... at some point in time it might be bad for a distro to have to pick sides, so they'll plunk the two together and get 'em working nice.

Re:KDE.

[digitaltraveller]

The main reason for two different APIs is because they are both, most likely, architectured completely differently from each other. One is OO while the other is procedural.

Well if you've ever programmed with GTK+ you will note that it is just about as OO as you can get with the C language. Everything inherits from GTKObject. By using nested structs. Each struct includes the entire struct of it's base class.

It all ends up being machine code in the end anyway, all I am saying is it would be nice to have a single unified API for KDE/GNOME.

the tree and the forest

[mj6798]

Microsoft is already technologically much more cutting edge than KDE: they are moving towards a safe, reflective runtime and a higher-level language with a built-in component model. KDE is still based on a language and runtime with virtually no built-in support for components.

The forefront of desktop technology is happening with Java (OSX, pure Java) and C# (Windows); C and C++-based efforts are widely deployed (Windows, KDE, Gnome), but they are already falling behind.

Re:the tree and the forest

[JabberWokky]

KDE is still based on a language and runtime with virtually no built-in support for components.

You sir, are one of three things: ignorant, a troll, or an idiot. KDE is entirely built on components, and I can swap them in and out and upgrade them and advance functionality without upgrading the whole.

Which brings up an important point - 3.0 should look just like the existing 2.2.1, with no new (user) features. The major number bumped up *because* of the component nature of KDE - the new version is the exact same (on the front end), but is binarily incompatable with 2.x. The back end gives advances that will allow the 3.x line to advance quickly on the front end.

--
Evan

Re:the tree and the forest

[mj6798]

KDE is built on components, but the language it is based on (C++) has no built-in support for components. You know, the kind of component support Microsoft built into C# based on many years experience with COM-like systems and their limitations.

That means that it is a lot harder to build component-based applications in the KDE environment than in an environment based on a language that has such support.

But, sadly, your response seems pretty typical of the KDE crowd: you don't even appreciate the issue and label anybody who disagrees with you a "troll".

Re:the tree and the forest

[GlowStars]

Mod this AC's comment up - it's dead on!

Re:the tree and the forest

[ras]

... the kind of component support Microsoft built into C# ...

The original post said "KDE is still based on a lanugage with no support built in for objects", without giving a creditible alternative to C++. Then you come along and suggest C# - a language that is not available on Linux yet! Give us a break.

I am willing to bet that Microsoft produced C# as a response to Java, and more specifically Java's VM. Java's VM killed two birds with one stone - portability and security. An impressive acheivement. Notice that componentisation was not on the list. At the time Microsoft pushed ActiveX as an alternative - a component technology. It was haled as snake oil at the time. The snakes that later arose were Code Red/Nimda/SirCam/.....

Re:the tree and the forest

[mj6798]

without giving a creditible alternative to C++. Then you come along and suggest C# - a language that is not available on Linux yet! [...] Notice that componentisation was not on the list [for Java].

That may be your list. In fact, Java is succeeding so spectacularly because it makes reuse and componentization much easier than C++. And, yes, Microsoft copied Java for just that reason. Now, why is KDE still mucking around with C++?

debian 2.3?

[mikey13]

I thought they decided Woody was going to be 3.0.

"The code name for the next major Debian release after
potato is ``woody''. This release will be
numbered ``3.0''."
http://www.debian.org/releases/testing/

it seems KDE is falling behind

[mj6798]

Microsoft is moving to C#/CLR. Apple's latest desktop is based on Objective-C and Java. Objective-C, C#, and Java have compelling advantages for developing large, component based software systems, foremost reflection, garbage collection, and (for C# and Java) runtime safety. Yet, the KDE effort is still largely based on C++, with little indication that there is any move to a more powerful runtime and more high-level language.

It's amazing how far KDE has gotten in a few years. But the industry is moving on to different technologies, technologies that greatly simplify applications programming. What is KDE doing?

Re:it seems KDE is falling behind

[AstynaxX]

Simple!=better for everything. For something like an OS or the basic window interface, sometimes you need comething that lets you get a little down and dirty [which Java simply does not do, and from what I gather neither does C#]. Ease of code is fine and dandy, unless it translates into slower, buggier, clunkier programs. Sure, computing power is cheap these days, but even so, not all systems are GHz monsters with 512MB of DDR RAM and 80 gig HDs... have to pay attention to the lower end of the user pool, and make it a good experience for all [something I know Java is not good at]

Re:it seems KDE is falling behind

[Jagasian]

Most of my expertise falls into software development in Java, but recently I have been pushing myself to do more C++ development on Linux. I don't want to rely on proprietary languages. Anyway, the modern C++ is far far different from the C++ of many years ago. Things have changed, and C++ is growing up. Sure its a very complex language, if you try to learn the legacy aspects of it, but if you stick to the core OO constructs in C++, then you have a nice efficient programming language.

I am coming to realize that Java has very little over C++. Garbage Collection is more of a buzz word than an actual worthwhile feature, and it should be noted that high-level memory leaks are still possible in Java. Sure they are memory leaks of a different kind, but unreleased yet unused memory is a big problem in many large Java software systems.

In addition, for even an intermediate software developer, how difficult is it to code your own destructors? I mean, really, at worst you have a few loops in a destructor. Anyway, most JVM garbage collectors are unpredictable and hog performance at the worst of times.

The most important thing that Java has over C++ is a comprehensive set of user-friendly yet powerful APIs. But in return, C++ as templates and STL, allowing for elegant generic software systems.

When it comes down to it, C/C++ are here to stay, until some real yet practical innovation in Functional Programming languages, mobile/concurrent languages, or Declarative Programming languages is made. I am all for newer better higher-level programming languages such as Haskell, Pict, Lolli, and Mozart-Oz, but Python, Ruby, C#, and other newer procedural/OO languages are not the revolution, they are not the future, and at best, they are nothing more than slight iterative improvements on an overused overdone, and over talked about paradigm.

Give me C, give me C++, and if you can, why don't you give me something new for once? I am tired of the same old Ford Tempo with a new paint job and a new name.

Re:it seems KDE is falling behind

[puetzk]

One thing to keep in mind is that KDE *does* use these higher-level things, as QT's QObject's implement them. It may not be quite as slick as having them in the language, but QT's moc does a lot to alieviate the shortcomings of C++.

Re:it seems KDE is falling behind

[am 2k]

I am coming to realize that Java has very little over C++.

What about a true dynamic runtime? In C++, you can't call a method when you don't have a pointer to it inside the vtable (some folks even confuse them with functions because of that fact). That gets you a speedy app, but many things (like EOF) are just not possible.

Re:it seems KDE is falling behind

[Karellen]

What's so great about a CLR???

All it does is allow you to "compile" your source into a more obfuscated form of source that no-one can read but you can ship off to any other computer where it will get compiled for real (usually JIT - which is IMO more like a cached interpreter, but that's just semantics) before being run.

All a CLR allows you to do is obfuscate your source a lot. We don't bother. Just ship the real source and allow someone to compile it themselves.

CLRs are just a klunky workaround for people who feel a need to hide their source for whatever reason.

Re:it seems KDE is falling behind

[mikael]

The most important thing that Java has over C++ is a comprehensive set of user-friendly yet powerful APIs. But in return, C++ as templates and STL, allowing for elegant generic software systems.

The thing is for normal application development you'll need the normal APIs provided by Java. Take for instance the way of creating a socket. In C++ you'll have to use the C-Unix API. This does not look good and is definately not OO. With Java, you'll just create a new DatagramSocket. But with QT that is changing. QSocket provides a TCP-socket.

I think that QT is providing some of the missing features to C++.

Mikael

Re:it seems KDE is falling behind

[mj6798]

Let me just counter a few of your misconceptions:

• The purpose of garbage collection isn't to eliminate memory leaks, it is to enable runtime safety (important when building software from lots of components).
• Destructors or reference counting in C++ are not substitutes for garbage collection because they don't accomplish the two things garbage collection accomplishes: runtime safety and factoring resource management out of interfaces.
• Reference counting or manual storage management are neither cheap nor predictable.
• The similarity between Java and C++ is mostly syntax; in terms of semantics, the languages are very different.
• C/C++ lack reflection and runtime safety, both of which are very important features for building large, reliable software systems from components. You can emulate reflection and try to substitute testing for runtime safety, but it's a lot more work.

I should note that I have used C++ since before cfront was released to the public, and I think C++ is a great language a number of specific purposes. Smart people can craft very efficient software and debug it in C++. But for getting a job done quickly, for working in large groups with people with different kinds of backgrounds, and for building reliable software from lots of components that are composed at runtime, Java and languages like it are simply better in my experience. And Microsoft, Apple, and many other companies seem to have drawn the same conclusion.

Re:it seems KDE is falling behind

[Androgynous Howard]

You are right.

It would be very nice to have a platform-independent intermediate binary format for KDE/Qt. That way you would have one application binary for all KDE compatible systems, instead of having hundreds of different binaries for i386 glibc 2.1, i386 glibc 2.2, Solaris, AIX etc.
Garbage Collection would also be nice, but the main advantage is IMHO the platform-independent binaries. Another huge advantage of using CLR would be to be able to program in many different programming languages without waiting for language bindings.

Open source advocates will say at this point that there is no need for an intermediate binary format because we have the source, but they are missing the point. Joe Sixpack users don't want to do ./configure --prefix=whatever && make && make install every time they install a new application. It is simply not an option for them! And even if there were an installer program to hide this complexity, compiling a program from source takes much more time than compiling it from bytecode.

But one thing to keep in mind is that Qt is a very successful commercial cross-platform library, and the fine people at TrollTech will only consider moving to a more powerful runtime when this runtime becomes available on almost all their target platforms (Windows, OS X, Linux, various commercial UNIXe).

I really hope that the mono project or some other project will succeed in making a CLR available on most UNIX machines. Then it would be possible to port Qt and KDE to C# or managed C++ without making big changes to the program logic. Maybe it would even be possible to automate parts of the process.

regards,

Androgynous Howard

Re:it seems KDE is falling behind

[Jagasian]

Exactly! That was my implied point. Java has a better (more modern, more complete) standard API compared to C++, and therefore, it is not KDE's job to change or augment the C++ language, or to replace C++ with another slightly better language. KDE exists so as to create a comprehensive platform API similar to the one available for Java. In fact, this is exactly what KDE has been doing all along. KDE's API isn't just about widgets. It is about modernizing the Unix API for Object-Oriented software development of interactive desktop applications.

The question is, "will it succeed?" I claim that KDE is already succeeding in regards to modernizing the Unix API. There is more to be done, but I know that it will continue to succeed for two main reasons: First, it is open, and second, it has lots of initial momentum behind it because of the genius of its originators. It is the same two-part recipe for success that Linus used to bring the Linux kernel from just another pipe-dream to an industrial strength Unix kernel.

Note that I am not implying that the original standard Posix APIs should be replaced. However, it is very important that another layer can be added ontop of the traditional Unix layer, so as to modernize Unix and bring it to the desktop.

Re:it seems KDE is falling behind

[Snootch]

But don't expect the slashdot crowd to understand you. They still hate java because it was slow a few years ago.

Now that was a nasty insult, as if a large proportion of /. readers were not familiar with languages like Java. That and deliberately waving the red flag by conspicuously not mentioning Java indicates that this may be a troll, but there is enough reason in there to be rebutted, so here goes:

Java is still slow. Yes, it's got brilliant portability, but it still uses an order of magnitude more resources than natively compiled code, and as KDE is already getting a lot of criticism for getting bloated, I don't think Java/C# would help at all. Bytecode languages have their uses, and I'm a great fan of them (well, Java at least), but it's not yet ready to replace the native code that does low-level GUI or console stuff.

Bytecode is a great idea, but it has its limits as regards efficiency, and this is (for now) one of them.

Mod this up, it's true.

[SaDan]

Sheesh... Come on, moderators!

In case you read the announcement

[mnordstr]

KDE 3.0 is scheduled for its first beta release this December and for final release in late February 2001

Is supposed to say February 2002...

"Gnome vs. KDE"

[Fenris Ulf]

I've always thought this Gnome vs. KDE thing was about as dumb as vi vs. emacs.

No, it's worse than that, it's about as dumb as 'vim' vs. 'nvi'.

In reality Gnome and KDE developers are not at war, in fact they've actually been known to be civil to each other! Hard to believe, I know...

Huh??

[Ars-Fartsica]

Why on earth would the KDE team move from a flexible, well known, openly standardized multiparadigm language to one that is closed, monoparadigm, and barely out of the gates????

KDE should consider using a interpreted language for desktop productivity apps exactly one year after Microsoft does. Try again in 2005.

Re:Huh??

[MSG]

Microsoft already does use an interpereted language for their "desktop productivity apps", and has for quite some time. Most of MS Office is written in Visual Basic.

Re:KDE people don't know "backport"

[puetzk]

kde3 is a much smaller change than kde2, which was a complete rewrite. Think of it as kde2.3, ported to qt3 and prepared for gcc3. This means two things to app developers and compatibility.

1) most of the differences are very minor, and in almost every case can be handled by a small bit of preprocessor magic. Most apps I know of that are converting to kde3 are taking this route first, making it possible to build for either platform.

2) kde3's release cycle will be *much* shorter than kde2's was, where there was no release for a tremendous amount of time.

In any case, there is at least one point release still planned for the kde2.2.x series, which should wrap up a last few outstanding issues before everyone moves on.

Re:Flamebait---- That stuff works!

[CajunArson]

Well I'll be damned, but the stuff compiled and installed without a hitch!

Now I have almost all the eye candy that the OS X guys have been yelling about, without having to use OS X ;)

I'd post a screenshot for everybody, but the slashdot effect could get me in too much trouble.....

Re:KDE. aRts ?

[loopkin]

I like this idea a lot !

But, close to that, here is my $ 10 000 000 multipart question:
why does KDE use aRts instead of esd, from the very beginning ? every application outta here uses esd, and especially commercial ones (flash, realplayer, etc.) ? why is aRts such an unstable thing (was leaking memory like hell in 2.2) ? why isn't aRts esd-compliant ?

someone has any answer ? :-))

Rock solid?

[poing]

Rock solid as 2.2.1? I'm running 2.2.1 stable on Xfree 4.10 / Kernel 2.4.10 and Konqueror is not stable at all - Try looking at local directories in tree mode, then select a few and move them around between different windows by dragging, segfaults all the time. Also happens sometimes when selecting several directories to delete at once. I have also experienced some segfaults while browsing websites which I don't recall the 2.0 ever doing. I hope they improve stability too cos this is getting a bit like Windows...

Objprelink? WAS:Re:Rock solid?

[anno1602]

Sounds like my probloems when I used onjprelink to compile kde and qt. Much faster app and kde starts, but unfortunately a little unstable. W/the SuSE RPMS that don't use onjprelink, KDE 2.2.1 is a bit slower (though still faster than any other 2.x) and rock-stable.

Greets,

Anno.

Re:Objprelink? WAS:Re:Rock solid?

[ksp]

I run KDE 2.2.1 on SuSE and I can just agree that it feels very stable. Faster than 2.1 too.

Features..

[steveargonman]

...bi-directional language support (for languages such as Arabic and Hebrew), multi-monitor (Xinerama and multi-screen) support..

Good thing Arabic is there, that might be needed to crack these terrorist manifests.

KDE on MacOS X / Darwin ?

[pedroziviani]

I'm a long time Linux user, but I've been using MacOS X for the last month and I must say I'm very happy with it, it's a quite impressive system. I can run XFree on it, and Gnome and most GTK+ apps on top of that, and even QT works well. Now, why not KDE?? QT works fine on XDarwin and so do most pure QT apps, and most of the GNU tools such as compilers and linkers.

Fink's (excelent UNIX Package manager for OS X) homepage says:
"KDE assumes it can do things with shared libraries that are only possible on ELF systems like Linux, *BSD and Solaris".

I'd like to see KDE developers working on whatever minor changes are required to make KDE apps run on XFree over MacOS X, so that I can use Konqui, KOffice and other tools without having to boot into LinuxPPC. Apple is now the world's largest supplier of Unix-based operating systems, and and by supporting those systems KDE could considerably expand it's market share.

Re:Great, just what we needed

[fault0]

> You crack me up... got any other hacky workarounds to make up for shitty design and coding in KDE?

You mean shitty design and coding of g++?

KDE natively under windows?

[/ASCII]

I'm curious: Would it be possible to use KDE natively as the WM on Windows, seeing how QT is available under windows? I seem to remember someone porting afterstep to windows so it IS possible to change windows wm. There is a link on the cygwin/xfree86-page about running KDE as an app under windows, but they use xfree86, I would like the possibility to use KDE as the only windowmanager under windows, using the native windows-version of QT.

Any comments/links/insults?

Re:Java Garbage Collection vs. C++ destructors

[ras]

This is an obviously correct and informated reply to the previous post. I guess the person who modded it down is a little wet behind the ears.

The orignal poster is correct, the primary advantage of garbage collection is run time saftey. A secondary advantage is convienence. These are two big wins. But in all other ways it looses out. It is slower, the run time of a program that uses it becomes less predictable, and because it blurs the point at which an object is destructed releasing other resources (like files) becomes problematic.

Oh, and C++ has had reflection (aka RTI) for some years. It is an add on - just like it is for Java.

quite right

[mj6798]

Yes, I fully agree with both your premise and your conclusion: it is a lot harder to build object-based applications in the Gnome environment than in KDE. And your point is?

Re:Java Garbage Collection vs. C++ destructors

[mj6798]

[GC] is slower,

Not at all. On some problems, manual storage management is faster, on many GC is faster.

the run time of a program that uses it becomes less predictable,

The only real-time, predictable dynamic memory management systems I have ever seen have been based on garbage collection. Theoretically, it's possible to implement real-time, predictable manual storage allocators, but nobody ever seems to.

and because it blurs the point at which an object is destructed releasing other resources (like files) becomes problematic.

Resources whose release has externally visible effects should be released manually, with safety checks. Unreferenced memory is a special case because it can be freed without any effect on the program and because checking access to it is too expensive.

Oh, and C++ has had reflection (aka RTI) for some years. It is an add on - just like it is for Java

C++ RTTI only gives you "instanceof". Java reflection gives you access to fields and methods (and it's not an "add on").

Apple the largest supported unix operating system?

[HanzoSan]

OSX just came out, most Apple supporters still use OS9, OSX has no software support (even worse than Linux) poor hardware support (worse than linux)

Basically OSX is freeBSD, and FreeBSD is not the most supported Unix. Solaris is, and then Linux. FreeBSD is actually the least supported flavor with something like 0.1 percent.

Thats Bullshit Nautilus is slow as hell

[HanzoSan]

Nautilus takes a full 5 seconds to load, I'm using a SCSI Cheetah State of the art harddrive with 256 megs of ram and Nautilus is the slowest loading program on my machine.

I could load Mozilla 3 times in the time nautilus takes to load.

I must admit, it does take Konq a f
New seconds less to load than nautilus making Konq slow as hell too, but its certainly fast enough when compared to the speed to power ratio.

Konq is as powerful if not more powerful than nautilus, and it loads at the same speed or faster,
in terms of speed I think they could increase speed via caching and Konq would load instantly because it would load with KDE itself.

Really, I have the harddrive speed to spare, the reason Nautilus loads slow is because they didnt do a good job caching it.

Nautilus 1.5 is about the come out, Its going to be as fast as Konq now and has vector based icons, Finally its BETTER than Konq however, Even if its better, they spent 15 million dollars on this?! A file manager?

I'm still disapointed in Eazel AND in Gnome, both had shitloads of money, and just burned right through it, I suppose the money was being used to buy fancy chairs and coffee machines for the programmers.

I see it this way, Nautilus needs money, Setup a Nautilus foundation SEPERATE of KDE, have slashdot post up an article with an interview called "save the Linux Desktop" where a nautilus programmer tells exactly why Eazel went down, and then tells of the plans they currrently have, and then allow US to pay say a fee of $5 a month to save the Linux Desktop, Take a page from transgaming. I mean afterall if Linux on the desktop is really so important, Then people will be willing to pay $5 for a few months, i bet people pay more than that subcribing to get the latest Beta CDs from Mandrake or redhat.