open tasks, jobs, unmaintained stuff, etc.

[Friedrich W. H. Kossebau]

Am Samstag, 6. März 2004 09:51 schrieb Guillaume Laurent:
> On Saturday 06 March 2004 01:34, Adam Treat wrote:
> > Really, KDE ought to come up with some rules for navigating out of the
> > murky, higgy waters.  My first rule would be, "don't ever employ the
> > Just Works^TM rhetorical device".  I mean who doesn't want a system
> > that Just Works.  I know I would like such a system.  Anyone object
> > to such a system?
>
> The problem is not that anybody wants such a system, it is that few people
> are willing or able to make one. And Unix/X11 is, historically, a perfect
> example of a system which is infinitely tunable but which requires tuning.

??? Ever had the idea that you started tuning because you actually _can_ do 
it? There are as many needs as there are people. Because some people are not 
able to cope with the multitude of options should never result in the removal 
of them (the options). Give those people and me some general working presets, 
but leave the fine tuning for those who like/need to use them. As long as 
someone is willing to care for the if-else-code (which is up to the 
maintainer).

You only tune if you are not pleased with the defaults. Or would like to 
explore alternative possibilities. There will be no development without 
choice. And there is still along road of development to go for KDE and UI in 
general.

> > More warm and fuzzies.  I'd love a balanced system.  I don't think
> > many would disagree with this.  But the real question is whether or
> > not "View Document Source" should be in the RMB?!  Right?!
>
> Yes, that question and thousands of others. And the answer is NOT "make it
> configurable" except to very few of them.

Oh, and how it is. I prefer a tailored-to-my-needs to a one-size-fits-all. The 
question is rather how much of it can be made accessable by some wizards 
(config dialogs, that is) to joe user. 

> Another problem is that many things are made optionnal because they don't
> work properly when turned on (like launch feedback or transparency for
> instance). It would be better to just remove the "feature" altogether.

You not really mean this, do you? How should things ever mature, when they are 
not set to the wildness? Mark such features experimental, hide them in 
configfile editors instead until they are done. 
BTW: What do you see broken with the launch feedback?

Friedrich