Slashdot Mirror
Why KDE Rules
diegocgteleline.es writes "Being a long time Gnome user and while talking with some non-KDE users, I realized that non-KDE users know few things about what are the "Good Things" of KDE. So I wrote an article about "Why KDE Rules" focused in KDE, with lots of screenshots and some texts - so all those non-KDE (or non-Linux) users can take a look at what KDE can offer to them, why KDE users use it and what they can expect about the future of the KDE platform if they choose to use it. Of course, this doesn't means that this was written to critize other desktops neither it means you should start Yet Another Gnome vs KDE flamewar..."
The same action in KDE will open 4 boxes:
- a dialog asking me which program I want to open the cd with
- a konqueror window displaying the contents of the cd
- an instance of kaffeine, playing the cd
Now, I know I could change all of this, but try as I might, it just doesn't work.In short, KDE may offer more, but GNOME just works (and audio-cd management is far from the only example that I have experienced).
Yeah, GNOME user here, but what I thought was a good idea when browsing that list was the file overwrite dialogs. Many times I've wanted to see a file preview before I overwrite it and have to browse to it manually. Though, it could look a tad better than it does on KDE....
I still couldn't use KDE however... I'm not very good with reading (my eyes jump with text, slowing me down) and I struggle badly with the Windows and KDE interfaces.
Debian (gnome) + arbitrary KDE apps = simplicity of Gnome + flexibility of K/QT = best of both worlds. On top of my standard debian system, I run kdevelop, quanta, cervisia, kompare, amarok, (konsole & konqueror as needed), qcad, celestia & umbrello (to name a few). Having run KDE for a few years, then having run Gnome exclusvely of the k* world, I couldn't be happier now.
In global context, this isn't a struggle of *nix vs the local franchose, or *n* vs. varius *nix gui toolkits vs the world; Rather its a struggle representing where free society should be focused, vs where corporate sellouts would rather your sense of justice be focused.
I'm a longtime KDE user. Some aspects of the system which I really like:
the ssh ioslave (fish://).. any KDE app I'm using can read and write to arbitrary SSH shells I have access to. Works anywhere. So I can use it in web forms to upload files to websites from remote ssh sites, or within kmail to attach files on remote machines, or with ksnapshot to save snapshots directly to my webhost, or with konqueror to browse filesystem HTML on remote machines.
I also use dcop functionality quite a bit. I have a fancy keyboard with special buttons. So I have all the music buttons bound to different actions using dcop (I use the 'hotkeys' app to do this). volume up, volume down, next, previous, play/pause, stop, mute, show-current-song, show/hide kmail, lock session, new konsole, new browser window pointing to homepage, new konqueror window pointing to home directory.. all are bound to convenient buttons using the command line DCOP client, and it was a synch to set up, since it allows you to investigate the interfaces at runtime, interactively.
Amarok is lovely. One little behavioural property I really like is how it allows me to quickly pick one-off songs to listen to. Changing the text in the search box updates your playlist dynamically. This means if I just type the title of a song, the playlist gets filtered down to just that song. Then, if I hit enter, amarok starts playing that song, and clears the search bar, which automatically resets the full playlist since there is no search query anymore. The method isn't foolproof, particularly for songs with common names, but it works 90% of the time for me, and the other 10% of the time I get a shortlist that will contain the song anyway, so it's still better than browsing manually.
KDE is just plain slick. Kudos to the developers. You guys are truly appreciated.
-Laxitive
Apparently you didn't really understan when I wrote "You can have a Mac OS-like menu bar" ;) There's no way Gnome can have a Mac OS-like menu bar. When I say "Mac OS-like menu bar" I mean: "Have a common file/edit/help menu bar at the top of the screen which changes when you switch between apps"
If you look at the screenshot closely, you'll see it.
By the way, KDE also has a gdesklets equivalent called superkaramba which has been included by default in KDE 3.5.0 (I didn't put screenshots of that because I wanted to show "technology" not "eyecandy")
If I wanted to show eyecandy and aesthetics I'd have show something like this
I say, give me something that will eat 10% of the resources and provide 5% of the functionality. Then give me 20 other somethings that do the same, but provide different functionality, and we'll have all of amaroK's functionality with only 10% of the resource commitment.
That's more or less my principle complaint against both KDE and Gnome: in order to get the hand full of features that could be useful, one has to add a bunch of stuff that at best isn't used and at worst gets in the way.
But, the good news is those 20 programs *do* exist, and I can use them. So long as no one is forcing me to use amaroK, I'm glad to see that it exists and that someone enjoys it.
In fact, it brings me great joy to know that both Gnome and KDE exist and that there are fans out there talking each other into using them.
First, people find them useful, and anything that improves people's lives (even in a very small way) is a good thing.
Second, they both help attract new users to free unix-like software, and give talented developers something fun to work on. Anything that makes linux and the BSD's more popular is good for those of us who love them.
Third, I'm happy that *both* gnome and kde exist, because so long as both maintain a large following developers will have no choice but to make projects able to run without requiring either. That's good news for those of us who prefer alternative environments. The day one wins is the day third party apps stop simply requiring libraries and start requiring that the winner be actually running.
The author of this comment is missing something: KDE is not a Linux only desktop. Try forgetting about Linux completely and think Solaris or FreBSD - or even Windows, and read it again.
I was using KDE on Solaris a while back, and it was every bit as powerful as it is on my Linux boxes. And that is because KDE does not use all sorts of Linux only technologies.
This isn't the full picture, though. In many cases, KDE will use the enhanced options of your OS, and provide backups for other systems. A simple example: Monitoring directories and files for changes. Linux (and possibly others) have a system that does notifications from the filesystem when something changes. For systems that can't do this, there is a polling implementation.
And in other situations, KDE will use extra features of your system. X extensions like render comes to mind.
And you mention FUSE - this is actually the KDE IO system that is exported like filesystems. That's a very nice idea, but it sort of goes against the argument that KDE reinvents this wheel.
KPPP was for a very long time a frontend to a command line ppp tool. But this turned out to not be powerful enough to be useful. If you start doing these frontends (and I actually have), you very soon run into situations where the reporting from them is too simple. One example is that GUI apps have progressbars for long running "things" - almost no text app provides a hook for GUI frontends to provide this. And you *always* have to parse whatever text is output to the user and present this in a GUI - and you can bet on this text to be different between every single release, and that your application is running on 117 different distros that have 117 different versions of your backend app. This means you have to figure out what version of the backend app this currently is, and parse the right one.
Now, add the multiple OS problem from above. Either you have to make frontends to the very different commands on FreeBSD, Solaris, h-pukes, AIX, and others, or you start adding GNU software to the requirements list of your application. Personally I hate having to install all sorts of stuff, just to run a single application.
Making frontends to text apps is often mentioned as a good idea. But that is only by people who have not actually tried implementing and supporting one of these beasts. If it should really be done, we should start compiling all text apps as a static library, and make the text app a frontend too. Then it could potentially work - providing both the GUI and text app authors have influence on the backend library.
Sometimes reimplementing the wheel is actually a better choice.