kicker's clock applet is a bone in my craw. why? too many features. in particular the background of the clock, which has at least 4 different possible modes (custom color, default KDE colors, LCD background and transparent), some of which are implemented by the clock applet, some by kicker and some by individual clock faces. this code was broken one way in 3.2, another way in 3.3 and yet another way in current CVS. i'll straighten it out for 3.4, but the effort wasted on this is silly.
and therefore the topic of the blog: features are like drugs.
when a feature is included in an application, some subset of the user base will become attached to it. very attached. they'll claim the need it, that they can't live without it. and fair enough, we come to grow comfortable with our configurations and tool sets.
but then if that feature gets removed or altered, you can be certain that somewhere some user(s) exist who are going to be really upset. there are few features that don't have fans. it doesn't matter how stupid the feature is, it can't be taken back as easily as it's given.
moreover, not all users like all features and options equally, just as not all people like all drugs equally. for instance, penicillin makes me break out in hives and pisses off my lungs (thank the goddess for tetracycline!) and marijuana just makes me drowsy and isn't particularly enjoyable to me. and so it is that some people just don't like certain software features.
this means that when a feature is added, some subset of the user base will clamor for it to either be removed, changed or be made configurable. the challenge in removing or changing it has already been covered, so making it configurable is often the path of least flamage. this is how we get insanely large configuration dialogs and things like the clock applet. ug.
now, i'm not advocating featureless software anymore than i advocate the outlawing of drugs. i am advocating that just as we should use drugs responsibly and often with consultation of an expert first, adding features is something to be done with much consideration.
kicker is now (just barely) off the top 20 bug count list, and the wishlist is under 200 entries long. amazing!
this is part thanks to a bug sweep i did one evening in which Maksim Orlovich and Renchi Raju joined me. they threw bug report nubmers at me as fast as i could read and decide on them. the result was rooting out a large number of duplicates, already fulfilled wishes, INVALIDs, etc.. kudos to both, you guys rock!
and speaking of wishlists, a certain Mr. van den Bergh from the Netherlands requested a feature in kicker on IRC. i requested he send me a design document detailing what it was he wanted in detail. to my admitted surprise and great delight, a few days later there appeared an OpenOffice Writer document with an excellent description of the desired feature. he included a screenshot and detailed configuration and usage information. it was really encouraging to see the user put in this sort of effort.
this has made it very easy to understand exactly what Mr. van den Bergh wants and how he would like to use this feature. this in turn empowers me to implement it as well as i can and with greater efficiency as he's done part of the work for me.
it also makes me feel less like a feature slave and more like a collaborator. who wants to be a slave?
so here's my wishlist item: i wish those reporting wishes would take half an hour out of their lives to produce a document that's even half as good as the one Mr. van den Bergh came up with and attach it to their entries on bugs.kde.org.
that would be too cool for words.
Subscribe to:
Post Comments (Atom)
14 comments:
PQ here.
Talking about features brings the word "bloated" to my mind. I've been waiting some time for your reaction to my disproof of your proof of konsole being lighter than xterm (xterm by the way is also bloated, have you ever used the Tektronix display for example?). I guess you just missed it, it's a comment on the "kde is not bloated" post.
Could you post this excellent document?
It's hard to know what's "half as good" as something you haven't seen. ;-)
>i am advocating that just as we should use drugs responsibly and often with consultation of an expert first
How boring. If I would like to get stoned, I'd definitely not ask an "expert" before. ;)
> If I would like to get stoned, I'd definitely not ask
> an "expert" before
rule #1 of trying out an "illicit" drug for the first time: ask someone who uses on a regular basis where to get good stuff for a good price and what kind of side effects to expect. they usually know this stuff pretty well. i would consider that person to an "expert" in that context.
to PQ:
i don't have time to do exhaustive benchmarking as you suggest. it would be fun to see the numbers, but i have other things to do =)
and there's really not much point because the numbers will come out pretty much as i detail them anyways. the code and memory requirements for a new konsole tab is really quite small, certainly smaller than starting a whole Xlib app. you can instrument the code to figure that out if you want; even easier than an elaborate testing rig.
with an X app such as xterm, i'd also expect the dynamic data segments to significant in comparison to the code or static data segments which can benefit from COW.
btw, RSS does not include libc and Xlib (and other shared libs). the code that may be shared in RSS is code that is unique to THAT application that the kernel may keep in a COW-appropriate segment.
as for start up times, i have a box here at work wherein starting konsole is actually faster than starting xterm, since i do some from within KDE (so kdeinit_wrapper prevents reloading libs) and the KDE appas are prelinked.
not to mention that while start up times affect me once per app (which for me tends to be fairly rare), things like memory usage and speed DURING app lifetimes are far far more impactful given how much time you spend using versus starting an app.
people who obsess about start up times as being some sort of defining statistic are naive and/or haven't thought it through.
The document can be found at:
http://aseigo.bddf.ca/dms/2/71_KDE_applet_suggestion.sxw
The problem with the clock is simple:
It's really something like 5 clocks glued together.
[quote]
when a feature is included in an application, some subset of the user base will become attached to it. very attached. they'll claim the need it, that they can't live without it. and fair enough, we come to grow comfortable with our configurations and tool sets.
[/quote]
Same goes for popup menu items too. They better be right first time or there will be hell to pay if you try to remove any.
explicit free mature*
hot mom pictures*
sexy oldies*
big housewifes tited*
old picture surf*
momanaladventures code*
daughter mature mums*
fucking gallery mature*
big milf white*
in mature moms*
Hi! I do see your point - at least in so far as maintenace doesn't become easier with added features. I don't quite see why people would want a feature removed as long as they can turn it off, though.
I already read in other posts about how kde supposedly would need simplicity to attract new users. I disagree when it comes to eye candy like the old school icon zoom or the analog watch background. In a certain way it IS like drugs. We're not talking compilation and config-files here, but toys. Everybody loves toys, especially no-tech users. I'm an architect btw.
I loved my KDE 3.x at first sight because I could play and fiddle, and if something didn't work I'd just turned it off - so what? In fact, I even set up new users just to fool around with different setups. One of the main reasons I switched to Linux is because I got addicted to the configurability of the look. I am a kde-feature addict, and I don't care if it is sometimes buggy or bloated, as long as I can turn it off when needed.
BTW, I _still_ really regret the icon zoom...
nice little blog you have here, if you'd like a look at my ##KEYWORD## related site, feel free...if you likePopupstuff that is.
MILF
Hey, you have a great blog here! I'm definitely going to bookmark you!
I have a assembly work at home
site. It pretty much covers assembly work at home
related stuff.
Come and check it out if you get time :-)
Post a Comment