KDE4: missing features from KDE3

[Aaron J. Seigo]

On Tuesday 04 August 2009, Pau Garcia i Quiles wrote:
> People still complain about KDE3 features they miss in KDE4 (for
> instance:

yes, of course they will. because people are people. there's a certain sort of 
bullying going on there where certain individuals, fewer with each release i 
might add, feel that if they just SHOUT LOUD AND ANNOYINGLY ENOUGH AT US that 
we'll relent, break our designs, go back on what we're trying to do and give 
them what they are used to at the expense of everyone else.

i have no desire to recreate kicker, for instance. it was good, but it had 
some really serious issues. issues that were irrelevant at the time it was 
made, but are quite relevant today. people who are wedded to kicker should go 
write their own panel system; they are free to do so.

but i won't go back on various design decisions and throw out all the benefits 
we're reaping due to those decisions. i refuse to fall into some misguided 
knee-jerk-to-the-latest-random-user-moaning design "methodology"

remember all the bloody screaming about folderview? well, someone's written a 
(poor) clone of folderview for GNOME's screenlets because it was the one thing 
they really wanted from KDE4. numerous GNOME users are commenting on it on the 
gnome-look.org page about it and how it's great to finally see an 
implementation of the idea for GNOME. if we'd listened to the users, we'd have 
run screaming from folderview. now it's the feature other desktops want.

> OpenSuse has this page:
> http://en.opensuse.org/What_features_is_KDE4_missing_when_compared_to_KDE3

half the things affecting plasma there are bugs (and not all in plasma, btw) 
and most of the rest are WONTFIXes. yes, things change. some design decisions 
that bring benefits mean other things that were done before aren't going to 
happen anymore. 

the ignorant part comes when someone goes "i can't adjust the translucency of 
the panel anymore to the single %!" without realizing the benefits that the 
design that precludes that brings (better config UI, proper control for 
artists, etc)

and as far as i'm concerned those kinds of things aren't even up for 
discussion. i'm tired of this topic, at least in the way it's approached.

you know what's REALLY funny about that page on en.opensuse.org? it doesn't 
mention _at all_ the actually useful features that are missing, like a 
plasmoid to show a random submenu of the apps menu so you can drag and drop it 
from kickoff into the pane (or wherever) and just get that branch of them.

even more "funny" is that when i commented on the wishlist item for that and 
noted that we should implement it but that it wouldn't be in this release i 
got yelled at by two different people on the report, completely without cause.

if the community of users wants to see improvement they can pick up a text 
editor and get their hands dirty, pay / coerce someone else to do so or shut 
up and be patient.

now, i'm all for a proper feature request system. bugzilla is not that, a wiki 
is not that, random emails are not that, a blog is not that. FATE, as used by 
opensuse, gets pretty damn close though (and it even has a kde client). one 
day i'll probably just say "screw bugs.kde.org for feature requests" and have 
someone set up a FATE install for plasma. and then we can get on to the 
business of proper feature request work flow.

i know that's probably a lot more, and not the sort of, feedback your were 
probably looking for when you wrote your well-meaning email. i just think we 
need to know where we're going ourselves first and foremost and deal with 
feature choice and growth issues wisely.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090804/68bb9bf6/attachment.sig>