> the idea isn't to hunt until you find a place you don't get kicked in the 
> face, but to ask why you got kicked in the face in the first place. you can 
> convince everyone you want here or elsewhere, but if it isn't an idea that  a 
> good number of the developers can agree with it won't happen. and you may 
> want to ask yourself WHY these people who tend to be pretty sharp are not 
> convinced.
0. People snapped at me when I wrote my first proposal.  The degree of
respect and tolerance in kde-devel is outrageously low.  For the first
batch of responses, I wondered "what, did I just suggest that KDE
developers commit mass suicide?", judging from the caliper of the
responses.
1. I submitted my first proposal to kde-devel for usability.  kde-devel
is not the right place to discuss usability.  It's kde-usability.
2. I really understand KDE (as many other FLOSS projects) is developer
driven.  But, let's face it, developers are hard to convince.  I tried
to persuade them at best.  Somebody else posted it as a bug.  It didn't
last open for *miserable* 5 minutes.  Someone in charge should at least
have checked how it would be like, instead of closing it "just because I
don't like it", damn the users.
3. Don't assume that because these people are sharp at programming, they
are sharp at understanding people (users).  Intelligence is divided in
several spheres, and people tend to have intelligence areas which are
sharper than others.  In fact, most developers tend to be rather dumb at
interacting with people.
4. Just because they *want* one thing, that doesn't mean it's the
best/fastest/fundamentally correct way.  Studies show otherwise.  What I
do accept is that if they want it, they *will* get it, whatever the
users say.  After all, they're the developers, and they aren't
contractually bound by what the user wants.  But it still doesn't mean
that what they want is better.  Developers comprise only the 5% or less
of the total target user base.  Or you might change the mission
statement in KDE.org to say "We build a desktop for us, damn the
others".
5. I think I will drop the subject.  I really wanted to contribute to
the KDE project.  I was thinking, the technology is great, why don't I
code the next version of my application to the KDE API.  Well, now I
think that really sharp developers will end up doing really sharp wrong
UI decisions and affecting the general outlook of my application working
on KDE.  No thanks.  See?  Good technology isn't at all the decision
factor for most of the people (CEOs, etc.).  It's human factors (will my
users gain in usability? will I, as a consequence, earn more money?).
6. Why conduct usability research when people aren't even committed to
fix what usability finds flawed?  FIVE minutes.
7. Don't suggest I got kicked in the face.  The whole KDE project lost
with this futile discussion.
> 
> as far as i'm concerned, the bottom line is this:
> 
> you list many valid objections to your idea in your latest email and answer 
> each one with what amounts to: "well, change the way you work, the way your 
> sys admin works and the way your applications work." for what? a marginal 
> improvement at BEST (and i don't think even that).
That's a plain lie.  Reread.  What I proposed generates minimal impact. 
The other proposal (really stupid IMHO), about changing app working
directories, requires much more developer and integrator work.  Plus, it
won't work with many apps (pine, e.g.  Press Ctrl-T in pine to attach a
file and see where it goes).  Really dumb.

NO one here or on kde-devel did:
* impact/risk analysis
* conclusive tests
* even think how it would be like to accept the proposal
There's no quality process.  And KDE developers have a tradition of
investing time in building workarounds to structural problems, instead
of contributing to fixing the structural problems.  Talk about NIH
syndrome.

"want floppy access? Use floppy:/, damn legacy apps"
"want apps that save to the desktop? change current wd! app doesn't use
cwd? damn the app"
"want the desktop to look tidy? tug away the mess into $HOME, damn the
mess in $HOME"

KDE developers live in a crystal bubble (no pun intended).

I proposed a single change which doesn't impact already existing users
and which can be reverted by mkdir'ing a single directory (not even
changing a configuration file).  No end-user application changes were
required.
> 
> you are trying to solve a problem that doesn't exist. for those who prefer it 
> where HOME == DESKTOP, they can set it (including system wide as you note).
Yes.  The default is insane.  It goes against research and practical
studies.  It goes against usability.  That's why I proposed the change. 
There are problems. I pointed out the thing about users not being able
to find files, about legacy apps saving to $HOME, about duplicity of
locations to store files, about the absurdity and illogicality of
hierarchically having a Desktop contained into the $HOME.

> 
> but trying to make this the default is IMO impossible to justify against all 
> the rearrangements and readjustments that will be required (not all of which 
> are within KDE's realm, FYI) just to address a problem that isn't a problem.
Which rearrangements/readjustments?  Can you list 5?  That evolution has
to move its data folder (listed now as a bug and being fixed) is
incorrect?  That you'll have to bear perhaps a bin/ and a tmp/ in your
desktop is aberrant?  That perhaps the developer uses his computer as a
developer, and watching a bomb icon appear on the desktop freaks him
out?  AFAIK even KDE apps save directly to the $HOME (or Documents dir,
which by default seems to be the same folder).  Three KDE-mandated
places to store files! INSANE!  Documents, Desktop, $HOME!  A support
nightmare!  Simplifying it down to one would bring great improvements in
human-KDE interaction.  Especially considering that the great majority
of apps save to $HOME and open from $HOME.

I don't understand.  All arguments against it have been "looks ugly"
(lie) "I'll have to change the way I work" (lie).

I'm really tired of the party line.  Good bye

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<