[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: glib in kdesupport: yes or no?
From:       Maks Orlovich <mo002j () mail ! rochester ! edu>
Date:       2003-03-10 5:17:03
[Download RAW message or body]


> Keep in mind though - the problem with duplication is choice
> vs. fragmentation, not the mere existence of duplication. As I said
> before, people *like* choosing from multiple email clients. What they
> don't like is say not being able to choose the best email client,
> because of their choice of web browser. Or losing possible users due
> to choice of devel platform. Or having to set up MIME handlers 6
> times.

What you're missing here is that often it *is* the platform is what makes 
something the best e-mail client or web browser for many people. Konqueror 
and KMail and KNode and Kopete are good in large part because they're KDE 
applications. It's their heritage that in large part makes them enjoyable to 
people. And no, it's not just a toolkit. Say LyX1.3/Qt -- a great application 
I use alot and greatly appreciate -- it doesn't /feel/ the same. 

What you're proposing here will damage a lot of those traditions. It's like 
your BlueCurve(R) - it may be (nominally) unified, but without life, without 
culture. It's shallow. It doesn't fit in anywhere, really. It's the Windows 
approach to the desktop -- unification through bland boxes, marginal 
consistency, and through common use of questionable technology.

In fact, what I think makes KDE special, and in many ways better than Windows, 
is that there is a consistent interplay of technology and feel, of a culture 
almost that means that applications will respond to the users in a certain 
distinctive way. Yes, it's all subjective. Best things often are.

Of course, your public statements already show that you don't understand the 
concept of a Desktop Environment. And no, KDE is no "desktop shell", so 
please stop treating it as such!

> itself, it gives users choice, and it gives us "failover" (if one
> project fails we have others to pick up the slack). The problem is
> when the stuff is not orthogonal/interoperable.

Is it? The problem in my book is when people put down their bugfixing tools, 
stop listening to what their long-time users are saying and start heading off 
to some far-away land with no compass and map. Sure, plenty of discoveries 
are made that way, but so are even more shipwrecks.

So I don't know about you, but I'll be away fixing some bugs, and then may be 
talking to some users, to see what they'd like. 

-S.E.

[prev in list] [next in list] [prev in thread] [next in thread]