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..."
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.
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.