ZDNet has published a review by Jason Brooks of eWeek Labs comparing the Linux desktops. He writes: "eWeek Labs found that KDE (K Desktop Environment) comes much closer to
delivering the sort of smooth interface that users have come to expect from the
Macintosh and Windows operating systems than does GNOME (GNU Network
Object Model Environment). In tests, KDE delivered snappier and more polished
performance than did GNOME on the same hardware." However, he continues, "neither desktop interface has yet reached parity with the established
players-pervasive support for features such as cut and paste across the
interface can still be unpredictable." Strange to have picked out cut-and-paste, as that should be much improved in Qt-3.0.

Comments

Is there any plans for the KDE team for providing configuration tools for linux (like configuring display, network, sound, boot things like that...)

That KDE 2.1.1 is already a stable and full featured desktop, I think KDE project should slowly start providing stable and reliable configuration utilities for linux (which are badly needed by linux users...). It also would be great to have uniform looking tools across all distros of linux.

These types of tools are problematic as distros vary so much. It creates a lot of additional work to do something for each distro, and often vary it for each point release... and then when all is said and done is it a good thing?

Please note programs like Webmin which runs from within konqueror very nicely, handles nearly anything you can imagine and works remotely via SSL. It's a pretty sweet package and it's basically a lot of Perl scripts. You might look at kaptain too as a quick development tool, and there are advantages in these ideas.

However... perhaps you have not been looking at the recent beta? It has configuration for Lilo, printer configurations including extensive Cups support, a new kernel configuration tool as well as time and DPMS configuration... I'm probably missing more (oh yeah, user and group configuraation) and I have not looked extensively at some of the network configuration going in, not to mention the work being done on the new kdm...

Admittedly it would be nice to configure X and such in KDE... There's still time for you to learn how to work on the code I suspect though. ;-)

I personally think that KDE development team has more expertise to put together a good desktop Linux distribution (or maybe I am just ticked-off that RedHat is not utilizing the full capabilities of KDE 2.1.1 in RedHat 7.1).

I am aware of several things that can make KDE a great desktop. I have done this at home with a severely modified RedHat 6.2 setup:

1. Get some real TrueType fonts. For some reason Type1 fonts do not display right, I think the Font Metrics is broken when anti-aliasing is enabled (the broken-up layout of the start page of the konqueror gives me this suspicion). When I used Win98 TrueType fonts, everything looked perfect. It took me a while to find some cyrillic TT fonts, but once those were installed I was able to read Russian news AND the fonts looked much better than they ever did in Netscape, AND it looked even better then under IE5.0 on a Win98 machine.
In short, KDE-2.1.1 + TTF = the best thing ever.

2. Enable lisa service used by KDE-2.1.1 to enable Network Neighborhood style SMB host/share browsing. This is a system startup level service (similar to sshd/httpd/inetd), and a regular desktop user would not have a clue about how this should be installed/enabled. On a side note - lisas' documentation under KDE-2.1.1 sucks. I had to go to the sources to figure out what needs to be done to make it work.

What bothers me, is that an industry leader like RedHat has missed these obvious (in my opinion) enhancements in their latest baby - RedHat 7.1.

After using KDE-2.1.1 on my home-rolled RH6.2 installation, the experience with RH7.1 was disappointing even after enabling anti-aliasing.

I may be paranoid, but it seems like RedHat is not giving all the attention KDE deserves. Maybe KDE could make their own Linux distribution, and enhance it along the way with things missing from RedHat 7.1 - ReiserFS, TTF, lisa, grub (a replacement for lilo), etc...

Fonts are a problem for Open source software. There simply aren't very many really high-quality TrueType fonts out there that have the correct licences. MS, of course, has the best fonts, but you can't just start redistributing their Windows fonts - that's a violation of their license. One thing that can be done is you can download MS's freely available web font package. However, you can't include it in a Linux distribution, because you can't redistribute the fonts. Someone needs to go out and make some high-quality TrueType fonts and make them available to all the world!

About lisa - how on earth *do* you configure it correctly? I've had zero luck.

I believe that KDE 2.2 will contain a totally new SMB implementation (based on a new SAMBA library) that will finally include proper SMB share browsing with no configuration. Yay!

The distro you describe in your last paragraph sounds an awful lot like Mandrake. Mandrake was started to add KDE to RedHat back before KDE was in RedHat. Today its practically a whole new distribution (still mostly binary compatible with RedHat though). Mandrake has a default KDE desktop, easy graphical install, easy graphical system admin tools, ReiserFS, grub, and more! It even automatically imports your Windows TT fonts for use under X. Mandrake 8.0 was released just today at www.linux-mandrake.com

My only gripes with Mandrake (I used to use it) are: I don't like their artistic style, they replace the nice K menu with their own using ugly icons and bad organization, and they use GTK for all their config tools instead of QT (can't figure that one out, since KDE is their main desktop). Everything works great though, and you can just ignore the ugly icons and GTK widgets.

How does what lisa does compare with what Windows does for seeing who's on the network? I only know a little about how Windows does it and even less about lisa. Oh, and I have not gotten lisa to work on my machine, but I had not put that much effort into it yet.

I think I have figured out part of the problem. Am I right that in order to browse SMB shares, you must configure lisa to use nmblookup? (or do I just have the IP addres range wrong? I can't figure it out from the README) Well, on a stock Debian system, the default is for only root to be able to run nmblookup. That might explain why nothing is showing up in lan:/ except for localhost. I'll have to look into changing that.

BTW, the documentation and configuration for lisa definitely needs to be improved. First of all, going to smb:/ should NOT bring up an error dialog! If what the user really wants in this case is to go to lan:/, they should be automatically redirected, not given an error!

You could probably deduce the correct network settings (broadcast address, etc for the most common usage case) automatically 99% of the time without even asking the user to set it up. This needs work. For the other 1%, you need to have more helpful help text. The help you get from the "help" button reads something like:

"For more information, look in the README file. To read the full manual, click here."

First of all, you are giving contradictory advice here (I know it's probably because of some kcontrol help template, but it needs to be fixed anyway!). Second, clicking "here" has no effect, because there is no hyperlink there! Third, this does not help the user FIND the README file (out of the hundreds on the computer), and it is not obvious where it is. I had to run a search on my entire /usr directory to find it. Fourth, once you do find the README file, it is of NO help if you don't already know a LOT about networking. The README explains a lot about how lisa works, but it doesn't tell you basic usage information like how to determine what IP ranges are acceptable for your particular network. It seems quite easy to configure lisa in a way that would either create lots of redundant network traffic or start ringing sysadmin pagers because they think they're being portscanned or something.

Sorry to rant, but lisa is simply way too hard to configure and use. With Windows, you simply plug it in and it works (for 99% of the cases. If you want something special, it requires some configuration). lisa should be no different. lisa sounds like a good idea, and I look forward to the improvements you plan to make.

BTW, won't the KDE 2.2 smb ioslave be able to browse available SMB shares in a network-neighborhood way? In that case, what will be the purpose of lisa?

Oops, I was wrong about nmblookup. Apparently there's some other reason that lisa won't use nmblookup. I have the "use nmblookup" box checked, but lisa won't list any SMB shares (or anything else, for that matter). nmblookup works fine on the command line. I know I don't have the IP addresses set correctly, but shouldn't lisa list the SMB shares using nmblookup anyway? And how the heck DO you set the IP addresses correctly?

I can see one simple improvement to the LISa configuration in KDE. It should not need one. Think about it, when you set up a linux box for networking, you specify which network the box is connected to. KDE LISa configuration tool then asks you to specify which network you want to browse. For most people, it's the same network that they have set their box up for. It seems that LISa configuration is confusing and redundant. When I was setting up LISa, I ended up giving it all the same data that can be extracted via `ifconfig -a` command. Maybe LISa configuration can be simplified by extracting the default settings from the results of the `ifconfig -a` command, instead of defaulting to 192.168.0.0/255.255.0.0 network settings?

In any case, here is how I got LISa working.
I added the following commands to /etc/rc.d/rc.local file on my RH6.2 box. Your setup may differ, so adjust accordingly:

this was very helpful. i had just installed RH 7.1 ang this was the first time i have setup LISa btw is it possible to mount the drives/directories using LISa?
(some of our machine are windows boxes) and how to i do that?

If you think that RedHat is not integrating KDE well you could try a different distribution. SuSE integrates KDE quite nicely in their 7.1 distribution and I had no problems with Mandrake either (have not tested the latest 8.0, though).

I used Mandrake 7.2, but I did not do any of the things that you mentioned. I installed the standard, everything worked right away and I installed additional program by hand (but not from the distro).
I have been running SuSE 7.1 for the last month and had no problems whatsoever. Maybe my hardware makes it easy (I bought a VA Linux machine), but I have had little problems with either distribution. And the configuration tools in SuSE 7.1 are superb.

Unfortunately Mandrake has adopted the Debian menu system to sync different desktops. The idea is that your menus will be the same under KDE, GNOME, WM, black box or whatever. What I find strange about this is loading those other desktops the menuing is NOT really the same on some. Anyway, I support diversity but have no time to play with other desktops and KDE works great!

If you write desktop files to /usr/share/applnk since mdk 7.1 the update-menus program will delete them. What I did was erase update-menus and /etc/menu-methods/kde. You still need kmenuedit and that's a pain and I hate what they did to the menus and kcontrol... so I built KDE from cvs in /opt/kde2. ;-) I now have both.

As to mdk 7.2 being buggy, the early release to get into Wallmart didn't help things. The re-release is pretty solid.

Though the nice thing about how the Debian packages of KDE are set up is that they use standard KDE menus for everything, then the shared Debian menu is a submenu off of the main "K" menu. So, I have the convenience of having the KDE organization and also the same menu structure if I were to go to blackbox or something else.

TT fonts take a person about 6 month to make a full set of latin only characters, there are almost no free TT fonts that you could include in a linux distribution. There was talk during GUAEC II about getting some of the big companies that back GNOME to contribute some money towards fonts. Fonts are an X thing so KDE can use those fonts as well.

So to provide the most use, a GUI front end could be a data collector for all this kind of raw information, perhaps populating a simple database that callable standalone scripts or programs could query to do the REAL config work.

A side benefit of taking this approach would be that someone could write a char-cell front end to the same database and scripts if they wanted to do system management over remote dial-up, or on headless systems.

The real heart of a tool like this would be the data repository and the API used to populate it and read from it. Writing the human interfaces would be something to do later and should be platform/toolkit agnostic.

I definetly agree. One of the biggest problems with MacOS and Windows is that the GUI is too tightly bound to the kernel. Since KDE must be seperated from the kernel by X anyways, providing a front-end is the perfect solution.

As others pointed out, it would involve much work for supporting the multitude of distributions.

But I believe it is still a good idea.

What KDE can do is provide a uniform modular front-end interface for configuring different things. Then it would be up to the distribution maintainer to do the distribution-specific work in the back-end.

For example the interface in the control center would provide the option to set network parameters. By pressing apply, a script is executed with all the parameters available. The script must be written by the distribution maintainer.

Everyone should be happy:

- Users have a standard interface on all distros.
- KDE team does not need to cope with each distro.
- Distro providers have an easy to use, intergrated configuration interface.

I was actually thinking about the issue of distro-specific config tools and especially how could KDE ensure (enforce?) a predictable and consistent user experience while letting the distro vendors distinguish themselves from others?

I do beleive that it must confuse more than it helps to have two configuration tools (...or "place to do config chores"?), each distro adding its own tool besides the KDE Control Centre. For newbies and other non-Linux folks, it does not make any sense at all. Methinks that might be where *nix looses points vs. (say) MSWindows or MacOS in UI comparisons.

So are you thinking a a different thumbnail/pane in the Control Centre to perform distro-specific chores? Or are you thinking of blending those with the rest?

I think this should be seriously looked into. In fact, it should even be the main objective of KDE 2.3, IMO, as it would tidy up one of the last few rough edges of the *nix User Experience.

Sounds like a pretty good idea to me...and is the way that good GUI apps are written. ie. split the UI from the functionality. Passing an XML message from the UI to whatever configuration script you like (provided by the distros or anyone else) would make it extensible, maintainable...are easy.

Please don't flame me för this, but I believe that is excactly what ximian setup tools are trying to do (http://www.ximian.com/tech/helix-setup-tools.php3). I haven't looked closely at it, but I belive the backend are written in python and it uses xml as "registry". I wonder if a kde front end would be possible? I have no idea if the tools introduce to many dependcies to the GNOME libriries, but it could be worth checking out.
At least the backends should not have any dependcies if they are reasonably designed (well to python or perl, but...). This could be a great oppurtunity for co-operation between the two camps. They could at least share backends and xml file fromat...
And a nother gripe would probably be the name, but that can change...
/Jörgen

I run KDE on a Linux system, and on a FreeBSD system. Is that really fair? Everybody seems to be neglecting the other OSes now, and it's like that at all of the projects that used to work on several OSes... KDE has been doing a pretty good job, though.

I think Linux users should first learn now to configure their desktop by hand and not by using config Tools. Isn't it enough that our best friend "Bill" fills up operating systems with these kind of tools which then....never work really good and produce strange not understandable errors, crash the system and so on....????

that's what i did,i'm using an extensively modified Slack 7.1 (kernel 2.4.3,Glibc 2.1.3 recompiled using kernel's 2.4.3 headers,gcc 2.95.3,latest binutils from HJL,it's not the GNU version,Xfree 4.0.3,etc...) but the only grippe i have is setting up GhostScript 7.00,gotta look if KDE's printing system will solve that one out.

I think it is not easy to say which one is better, GNOME or KDE. It is just that I personally feel more confident to use KDE, simply because it uses much better underlying GUI library (QT). QT is written in C++, it is object oriented and it is very very well designed IMHO. GTK on the other hand tries to be OO, but is looks to me nothing more than C-ish hack for the OO. I don't want to discuss the look, or copy-paste features, since they are part of personal preferences. KDE simply has better GUI library and this is a good reason to use KDE for me.

Be careful not to take Object Oriented languages for Object Orientation. The GTK+ library IS Object Oriented, but it is written in a programming language (C) that doesn't support OOP. Many of the things that GTK+ must do at run-time (e.g. type-checking), are done automagically at compile time by the C++ compiler.

That's nonsense. GTK+ might be C and the coding style looks like C, but it is fully object oriented in every definition of it.
C++ is also a hack; it's just a hack that you can't see because the C++ compiler does it for you.
Even if GTK+ is really a hack, who cares?
It works fine.

And what has GTK+'s underlying technologie has to do with how good it works?
A button is a button, no matter in what language/toolkit you write it.

Interesting... I was not aware you could do OOP in C. How does one do inheritance? Public vs private access? What about virtual functions? If the programmer has to keep track of it, I would consider it a hack.

inheritance is done by making the super-class a member of a struct. Public vrs private is done by prefixing something with '_', virtual functions are done with function pointers, when you make a new Gtk widget you make a call like this

GtkWidget *my_widget = gtk_subclass_new();

this takes this function pointers in my_widget and assigns them to the corrent functions, then when you call a function you do some thing like this

while this might look kind of of confusing you dont have to keep track of this yourself, it's done in Gtk, there's even a base class GtkObject that helps the people hacking the Gtk source from doing this stuff themselves, all your code looks like is

Even if someone gets used to the GTK+ style of something that looks like OOP, you still have many disadvantages just because it uses C. For example,
you can't have two functions with same name, but
different arguments, you can't define your own operators between user defined objects, you can't have default values for function parameters, etc, etc...
Plus, it is well known fact that C++ is much more adapted for large programs than C.

There's nothing wrong with C, most realy big, system intensive projects are written with C, look at all UNIX kernels, or big clustering systems, or a GUI like photon. When it comes to apps that 'you' write you can use the Gtk C++ bindings, or you can you can even use a simpler OO language like object pascal(good language for large projects). If you dont trust C then I hope your not using UNIX, because about 90% of the stuff your using is written in C.

I never said there was something wrong with C. I use it myself. OS kernels are special programms which need to be optimized for speed as much as possible. This means, that they are better to be written in C (some critical parts even in assembler), than in C++, since speed of execution is the only category where C is superior to C++. Most of the UNIX stuff is written in C, because it was written way before C++ was invented.
You can always write a large application in C (you can even do it in assembler, trust me), but it is easier to use an OO language. If you don't believe me, go to the nearest software company and ask them what language are they writing their applications in. I doubt they will say 'C' (here I mean strictly 'C', not 'C++'). And I never said that I don't trust C, so please read my postings carefully before blaming me for some stupidity I never claimed.

I never said there was something wrong with C. I use it myself. OS kernels are special programms which need to be optimized for speed as much as possible. This means, that they are better to be written in C (some critical parts even in assembler), than in C++, since speed of execution is the only category where C is superior to C++. Most of the UNIX stuff is written in C, because it was written way before C++ was invented.
You can always write a large application in C (you can even do it in assembler, trust me), but it is easier to use an OO language. If you don't believe me, go to the nearest software company and ask them what language are they writing their applications in. I doubt they will say 'C' (here I mean strictly 'C', not 'C++'). And I never said that I don't trust C, so please read my postings carefully before blaming me for some stupidity I never claimed.

I did say nothing about how good GTK+ works. It might even work better than QT, I just said that personally, I am more confident to use KDE, because I know it runs on library that is OO and written in C++. If you consider C++ just a hack, than probably every programming language is just a hack too. Even if GTK+ allows you some sort of inheritance (but only once, you can't inherit two different structures, yes, because its a hack), maybe easy creation of new widgets, it is far from being OO.

Wrong. GTK+ is fully OO.
It can do inheritance, virtual functions, public/private members, type checking, bla bla bla.
If you just take a look at the GTK+ source code, you'll know that!

And about inherit two different structures:
Object Pascal/Delphi can't do that either, but dispite that it's still a very good language used by many people and companies.
GTK+ doesn't support multiple inheritance, but it will support interfaces like in Java in the upcoming GTK+ 2.0.

maybe so, but the lack of expressiveness for OO would make things more difficult to do and understand. say, how do you think a "chain of responsability", or a "decorator" look in the gtk+ style of oo? it's doable, but you're missing the point. one could do oo in fortran if you were willing to type a lot, which gtk+ users certainly have to do.
btw, it sounds really stupid to say gtk+ is oo in every definition of it? where the hell is that definition?