Well, George…
February 7th 2010 12:37 pm
You don’t have to use KDE 4. (And I can’t believe I’m actually having to make that part clear) Really people should use whatever makes them most comfortable, productive, fits with their needs better, etc. Just use what you want.
With that said, saying that you do not like desktop effects is not a good reason to avoid KDE 4. I happen to like desktop effects but I’m not using them, even though I’m in a KDE 4 desktop (due to a stupid problem somewhere in the driver toolchain). In fact I know for a fact, given that I recently tested it, that KDE 4 works just fine even in a Composite-less X11. So I forget what propaganda technique it is (straw man argument?) but in short that reason has absolutely nothing to do with KDE 4.
Really your whole rant could have been more concisely expressed without a single reason (as after all, you should be able to use whatever desktop environment you want) and you wouldn’t have people nitpicking your exact reasons that way. ;)
I think what he meant was that the fact that he preferred working with desktop effects turned off was being met with rude or discrediting comments. If true, I would say it’s a terrible attitude coming from a developer.
Yes, Daniel’s hit it there.
The other point is that I’m tired of people telling me that I should upgrade to the all-singing, all-dancing KDE 4 when I have my own (in my opinion, valid) reasons not to.
I agree with both comments here. The problem isn’t that KDE4 has shortcomings, but that users are being treated like idiots if they have a problem with it. I hope there is a second side to Mr Wirght’s story, but this blog post doesn’t address the true problem – at all.
I think the lesson is that you shouldn’t get into technical arguments with drunk developers. Or rather, when you do, don’t get all pissed off when they don’t make coherent arguments.
Until there are a large number of sober KDE devs that hold the belief that battery life doesn’t matter I don’t see the problem at all.
I definitely agree that people should not be harangued into using KDE 4 if they don’t want to. And although George’s point didn’t really hinge on the desktop effects I also don’t want people coming away with the impression that KDE 4 requires desktop effects to be enabled.
Additionally, the KDE devs refuse to add the same level of polish that non-composting KDE3 had to KDE4 non-composting users:
https://bugs.kde.org/show_bug.cgi?id=196379
That makes KDE4 without composting look terrible. People prefer pretty cars, pretty girls (and guys) and pretty desktops. Go as Alice (Apple).
@Dotan
Implement fake-composite effects has a price. And that price is high. Plasma and Kwin developers make it pretty clear over and over again. That’s not lack of polish, it’s a design decision made with long-term goals (ie not turn the code base into a huge piece of unmantainable crap)
I think the desktop effects point was a minor part of Greg’s original post. The larger issues is the seeming attitude shift of a number of developers toward users. You can see this in certain bug reports. The idea that “experts” know better than users what they want, which results in KDE 4 being less configurable than KDE 3 in certain ways.
I agree with part of what he said in his original post, but I feel that the developers who display this attitude are a small minority of the people working on KDE 4 (a very vocal and powerful minority, granted, but a minority none-the-less).
This has been my experience. A few developers seem to be unwilling to accept feedback from other users (especially constructive criticism), but there are certain areas of KDE (such as the Akonadi project) where the developers go out of their way to address user concerns and give users flexibility in their configuration choices. I think this represents by far the better part of the KDE community.
It’s clear that those few vocal “leaders” have driven off a fair number of users. A lot of people I known (in real life) who switched from KDE to Gnome after KDE 3 was no longer supported complain about the lack of certain configuration options in KDE 4. I think this was also part of the reason we lost Linus as a user.
However, I personally think the new technologies in KDE (Akonadi and Nepomuk, for example) have actually made KDE 4 far more flexible and configurable than KDE 3. Akonadi, for instance, allows you to plug in all SORTS of different backends for your PIM data. It’s even pretty easy to develop your own. That gives the user a lot of power. Some areas of KDE still lag behind (such as Plasma) where a lot of heavily requested configuration options have been slow to make it into the interface. Nevertheless, things like being able to tie activities to desktops that users have complained about since KDE SC 4.0 are slowly making their way into the code base.
Something I noticed that is that KDE3 was very console-user friendly. In many ways, you could make it feel like a sort of icewm with a filemanager/browser which did not suck.
And many users wanted it to stay like that. And these are angry at KDE4, an they will never be happy, because they will always, forever find absurd minuscule nitpicks to dismiss the whole 4 series. Because the 4 series is not addressing their needs anymore: Nepomuk/Plasma/kwin/phonon/akonadi are fundamentally making KDE4 a graphical environment. Nothing there benefits fundamentally the console users, all the new stuff is pure overhead to them, an they feel like second-class citizens.
Of course, they are met with scorn and mockery: all that they complain about is what makes KDE4 great! They would have been much happier with just oxygen as a new theme, but that was not going to happen, because the artists making the theme care about the new effects; we are also lucky not to have “artists” who think six point (bitmap) fonts are ever acceptable*. They would like strigi to go away, because it consumes resources, but that is not going to happen: if the desktop is going to move forward, it will need the semantic parts — otherwise, why change anything: KDE3 was a very good desktop of the 00’s. And so on.
Basically, the issues raised are real issues, but they should not be addressed. Instead, the users complaining so loudly should be directed to enlightenment or icewm, both very good ones much better suited to their needs than KDE3 ever was **.
* As a user, I’m pretty happy the devs are not wasting their time on such silly issues: it is a bug, yes; if it makes you feel better, of course, correct it. But as long as your time is short, I’m pretty confident you have other issue to tackle first.
** Usually, when the rants “I will never use KDE4″ start, you know they will end by “I am now using XFCE, but 2 is not as good as 1 was”. This PROVES KDE3 was never a good choice for them in the first place, they never got where it was going anyway. It was pure chance that they could customise it to their needs.
Nepomuk and akonadi are non-console? I suppose so, but you certainly don’t have to be a heavy (or even moderate) plasma user to get a lot out of them. At least, not if you are opening an image viewer, like gwenview, and you have lots of tagged images.
There are three different problems here:
1 : Old kde 3 users who want some feature which is sometimes not feasible, because it would get all the code base dirty or the like. Also they get angry when they are told that.
2 : Developers who instead of saying:
“The feature you request would be difficult to do in a clean and tidy way and we have more important things to do right now but maybe later we could implement it, of course you can implement it yourself and if you do it well, we could add it here”
Say:
“You’re a corner case, stop being so old and get accustomed to my way of thinking. we’ll never implement that feature, it is UGLY.”
3 : And normal kde 4 users who like it and want to push it forward. They just try to make people use it or at least give a compressible explanation of why they don’t, so at least they can rest in peace knowing what the problems are and thinking of possible solutions.
The solutions to this problem would be to get in each other’s shoes:
1: Old kde 3 users should understand that some of the things they ask for could get the code base dirty, or be very difficult to achieve by the developers.
2: Developers should understand KDE 3 users might really love those features and if implemented cleanly (As a conf where it doesn’t make the ui ugly) they would mostly harm no one. So they should treat them softly and tell them someone might do it or that they can try to do it themselves / ask someone else to do it.
3a: KDE 3 users should understand that KDE 4 pushing users only want to help KDE most of the times, and should provide all the info they can and not only say. “I can do what I want and I won’t use it because it is rubbish”. Try to help. (george actually gave constructive criticism which is good)
3b: Kde 4 users should understand that these KDE 3 users have their reasons to not switch and hear their reasons if you have a solution speak it if you don’t try to make one (Even if it is only a brainstorm or a whishlist)
PS : Sorry if my english is bad
Akonadi and nepomuk are not technically not console, but if you are an old-school unix console user, they don’t help much. A lot of KDE3 “from my cold dead hands” attitude come from such users, who typically also liked one or the other of the apps.
I am not saying these techs are bad. on the contrary, they are great. I am a perfectly hapy KDE4 user (with a repressed desire for a top-of-sscreen app menu, but hey, you can’t have it all). I simply say that there can be no reconciliation with certain KDE3 users, because in their workflow, all that mkes KDE4 great is a hindrance.
Of course developer attitude to their requests is less-than-polite! Their demands are insulting (not the words, but what they imply: all the KDE4 develoment was a hugely destructive endeavour, for them). And there is no use catering to their needs: their needs are catered for by the more minimalistic environments.
Imo the whole problem is a lack of respect. [1]
Some bug reporters have to accept that their problem is not the most important one, there are only so many developers with so much time. They constantly have to decide which bug reports they ignore for the time being and which they put energy in.
Yet some of these reporters are so stubborn that their efforts in the end result in an energy drain of the developer without actually putting that energy into good use.
It is really annoying if you have “been there done that” and bug reporters do not accept your specific knowledge in this case keeping on babbling and in the end getting a bad picture of the dev and maybe even KDE. It is exhausting to explain all the reasons in detail instead of working on the code and it gets even more exhausting if your reasons are simply dismissed.
But in fact respect is no one-way road. I understand when users are put off by answers that imply the dev knows better and something is called no proper use case. In general there is imo no real answer to this whole problem [2] other than trying to see the issues at hand from a different perspective. Accepting that some issues are really important for some users might explain their “stubbornness” on this, their passion. So one thing that can be done is to be friendly, I very often thank users for their bug reports as they are a major key in improving code and also show dedication on their side. I work on programs to improve them for the users and in fact because coding is fun. ;)
[1] I write of devs and users here, but I mean that on a bug report basis, so a dev not working on a program yet filling a bug for it is in fact also a user.
[2] Problem beeing the different knowledge and experience that is very hard to transfer.
First off, excuse me for cross posting this to both blogs, but I got to the conversation a bit late and felt that the same comment is relevant to both.
I was one of the apparently nefarious developers at the Toronto release party, so I’m aware first hand of people’s behaviour at the time. I’m not sure if George has a backlog of frustration and that our get together was the straw that broke the camel’s back, but I have to say George: your account of people’s treatment of you id pretty melodramatic and not very fair.
To characterize the tone of conversation that night I’d like to fall back to sports metaphor. Imagine a room full of basketball* fans. Their team drafted a new point guard two years ago and after a shaky start he is now taking most of the minutes away from the solid veteran who used to man that position. Some fans like the new guy. Some fans like the old guy. The new guy is exciting, is the future of the team, but like any player, has some faults. The old guy was great in his day and can still do the job really well. He too has some faults…. So to conclude my already tired metaphor, our table fell to (what felt like to me, anyway) good natured arguing over the pros and cons of each player. Stats were sited. Appeals made to emotion. Math-ups versus other teams debated. The discussion was passionate but I’m sad to see that George seems to have taken it more to heart than it was ever intended.
In the end, my metaphor really breaks down when you compare free software to sports players because if my favorite player has an ugly shooting action, I can’t turn up to the practice facility and start giving him pointers. At least with free software, I do have that chance to make things over in the way I’d like to see them.
George, do you recall razzing me about who one the ashes? I’m sorry if the tone of discussion seemed to coercive to you; hows this for a deal? next time we sit down for a few beverages I’ll refrain from blogging about Englishmen sticking it to me about my choice in cricket teams and perhaps you might want to reciprocate WRT desktops?
[*] insert the sports team metaphor of your choice. George, I have no idea if an equivalent exists for marksmen, sorry ;)
I think what bothers me most about this is that in at least once instance I can think of:
A. The user reporting the “bug” provided a patch for the behavior.
B. The reporting user (and several others) gave solid use cases supporting the desired feature.
C. The bug received LOTS of votes from the user community.
D. The developers shot it down because it didn’t fit with their vision of the too. Not because the code was infeasible (there was a working patch submitted!) or made the code-base messy, but because they didn’t want to support the feature.
Now, I can understand wanting a minimalistic interface. Some people find that more conducive for their workflow. But the right solution is to make the new features optional and add a configuration setting for them, not to reject them out of hand.
atomopawn,
I can sometimes be hard for non-developers to understand developers :-)
I suspect that pretty much every developer has rejected a patch / bug report. I can think of a few instances myself where I have had to reject a patch because I know that it will be too slow, or have a high maintenance cost, or not be in the direction I want to take the source code, or just plain require too much work to integrate.
Say you write a small 10 line patch to add a new feature. Now I have to write a unit test case for that, write a performance benchmark for that, add in a configurable way to enable/disable that feature, find a way to expose that setting in the GUI and so on.