Why do you prefer KDE?

[Duncan]

Bruce Byfield posted on Sat, 21 Dec 2013 18:45:13 -0800 as excerpted:

> As you may have heard, KDE recently topped the Linux Journal's Readers'
> Choice Awards.
> 
> That got me thinking. Why do people prefer KDE? What advantages do you
> think it has over other desktop environments?
> 
> Warning: If I get enough replies, I may use them in a blog entry for
> Linux Pro Magazine.
> 
> My thanks in advance for any replies.

In a sentence:  I use kde for exactly the same reason I run gentoo, and 
to some extent, exactly the same reason I run Linux: all three respect 
the user's right to choose exactly what and how they want things far more 
than most alternatives.

I've never seen either a desktop environment or distro I was satisfied 
with straight as it came out of the box, and I doubt I ever will.  I have 
quite particular demands and expectations about my ability to make the 
tools I choose to use work /my/ way, and I don't take very well to either 
my tools or their creators saying there is only one right way to do 
something, it's their way, and if I don't agree, I'm simply wrong, when 
it's my box I'm working on and my time I'm spending on it!

So I tend to be a HEAVY customizer, to the point that other users of the 
same tools don't even recognize my customized configuration as the same 
tools they're running too.  Both kde and gentoo tend to support my level 
of customization far better than most alternatives, so they're the 
choices I've made.  And Linux, of course, is built and thrives on that 
level of freedom as well. =:^)

It should be obvious from the above that don't always agree with all 
choices made, but the great part is that in general, all three projects 
respect the user's ability to make their own decisions, and that's what I 
value.

As an example, both Doug and Graham mentioned how badly kontact, kmail, 
and basically the entire kdepim module has been screwed up during kde4.  
I won't argue a bit with that as I had exactly the same sort of issues 
with it.  One day after kmail had eaten yet another email, I asked myself 
why I tolerated that sort of behavior from an app tasked with handling a 
set of basic network mail protocols that have been around in some form 
longer than the internet itself -- email is NOT rocket science and it 
hasn't been rocket science for some time!  It's a stable set of protocols 
with all sorts of stable choices for handling them, and there's 
absolutely no reason people should be expected to tolerate the kind of 
mail handling issues kmail/kontact/akonadi brought them!

That day I set about changing things, for me anyway!  Within a few weeks 
I'd found my chosen alternative (claws-mail, both as a kmail alternative 
and with its feed-reader plugin, as an alternative for akregator as well, 
since akregator is part of the same kdepim suite and was in line to get 
akonadified as well).

But I didn't stop there.  With that gone, I decided I didn't need akonadi 
or even for that matter, the entire semantic-desktop thing, at all!

And because I run gentoo, I wasn't simply limited to turning off semantic-
desktop at runtime.  I switched a few build-and-install-time USE flags 
and entirely uninstalled a whole SET of dependencies.  Akonadi, nepomuk, 
redland, rasqal, virtuoso, soprano, mysql, kdepimlibs, kdepim-common-
libs, libkdepim... all gone along with kmail, akregator, and kaddressbook, 
the bits of kdepim I had been using.  (Strigi remained a dependency as 
part of kde required it to build, but it's a tiny package by itself and 
without a data backend installed, it couldn't actually do anything... it 
was purely a build-time dep of a few other kde packages including I 
believe kdelibs.)

And not only did I have them entirely off my system, I was actually 
rather astonished at how much FASTER my system ran without all that junk 
loading it down, too.  Even with nepomuk turned off at runtime, the 
system had been rather laggy since I had installed kde4 in the first 
place.  But removing it was like getting all the viruses cleaned off of 
somebody's MS Windows machine (when they don't know/care enough about 
security to keep it clean in the first place)... or like I had just added 
a couple extra cores to my CPU!  It really WAS that dramatic, and it's 
something that really surprised me, as I hadn't expected any benefit but 
not having those packages around to keep updated any longer!

Since then I've come to the conclusion that at least some of the slowdown 
people still often say they have with kde4 in comparison to kde3 is due 
to all that semantic-desktop junk.  Too bad few distros offer a proper 
kde-lite option without that stuff even installed. =:^(

But exposing that sort of choice to the end user is exactly what gentoo  
does /by/ /default/ at the distro level, and exactly what kde does /by/ 
/default/ at the desktop level.  It's part of their design philosophy -- 
part of the point they even /exist/!  There are certainly exceptions, but 
that's the point, they're the exception, not the rule, and time and 
again, it's exactly where those exceptions occur that are some of the 
biggest pain points for the users.

Think about it.  If kde had provided its usual level of choice with the 
whole kdepim/kontact/kmail akonadification fiasco, would it have been a 
big deal?  No.  Users would have decided they thought the default was 
stupid and would have gone and changed the config to something that 
worked for them.  Because that's part of what makes kde kde, the ability 
to do just that.  And when that ability isn't there...

Well then, people end up doing it anyway, but with non-kde apps if they 
have too.  Just as I replaced both kmail and akregator with claws-mail, 
here.

But it's a pain-point that should have happened, and I argue, would /not/ 
have happened, had kde followed its usual practice and had exposed that 
as a configuration option, either by offering an alternative kde mail 
client, or by making the akonadi integration in kmail a customization 
option.

And look at kde4 itself.  Same thing there.  Early kde4 might have worked 
the way the developers intended and that's why they said it was ready for 
users.  But kde's users have OTHER ideas about how they want their 
desktop configured and working, and are used to GETTING it that way!  And 
it was precisely all those unusual user-specific customizations that were 
still broken when the kde devs were so insistent that kde4 was ready for 
use, while most of their users were unfortunately finding exactly the 
opposite, that it was still horribly broken, not because the way the devs 
used kde was broken as it clearly worked when people did it their way, 
but because all the ways kde users were /used/ to reconfiguring kde to 
work their /own/ way were now broken, and that was and remains one of the 
biggest reasons people choose kde in the FIRST place!

Fortunately, indications at this very early point in the kde5/frameworks 
transition are that in general, kde and its core devs seem to have 
learned the lesson, and in fact, modularity and the ability to pick and 
choose only the bits that work for you are one of the big selling points 
of kde5/frameworks.  I can't help but think back to what were kde4's big 
selling points at a similar point in its development... all about 
semantic-desktop, etc.  And I know which one I'd pick given the choice, 
both back with kde4 and now.  Unfortunately, kde did apparently have to 
learn that the hard way, but fortunately, indications are that they 
have.  Given a bit of time, I guess we'll see.  =:^)

(As with Doug, you have my permission to quote from the above, with or 
without my name attached, if it fits your article.  And I'm looking 
forward to reading that article, too! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.