A look at GNOME 2.14, comparison to KDE

[Anders Storsveen]

Mr Bulldog wrote:
> some people are two finicky about small things and if they don't like
> it they can move to gnome or what ever for the time being. Some
> features I don't like in Kde is the amount of options in it, but what
> do I care, looking at the overall picture at least I can get something
> done much easier than gnome or other desktop environments. Really we
> should be praising all the kde developers, if you don't want all of
> the great features try kde light. However this argument is just
> rambling on now.

lol, why do everyone think it's the features that is the problem? it's
not the features, it's the way some of them are presented.
try not to make a flamewar out of this please. saying, "if they don't
like it they can move to gnome or what ever" is kinda not what this list
is all about.


>
> On 21/02/06, *Aaron J. Seigo* <aseigo at kde.org <mailto:aseigo at kde.org>>
> wrote:
>
>     On Tuesday 21 February 2006 12:06, Janne Ojaniemi wrote:
>     > But couldn't the same functionality be achieved without those frames
>
>     of course. however, it is not as easy as some tend to think to fix
>     due to the
>     added complexity of the code. sometimes it's not even possible to
>     get it
>     right without rather large changes. and that was my point: it's
>     not fast
>     work, it's not easy work, it's not fun work and it's almost always
>     thankless
>     at the end. the rather flippant "change these 10 things to make it not
>     crappy!" lists really get tiring after a while; esp after i've
>     seen that list
>     100 times already.
>
>     > that frame the content-area. Since the background of the
>     content-area and
>     > the background of the window are different color (by default at
>     least), you
>     > have the differentiation right there, without having to use grey
>     lines.
>
>     ... and test with different colour schemes and widget styles.
>
>     > I think that all else being equal, an app that looks good is
>     > inherintly more usable than an app that doesn't look good.
>
>     well, it may be more pleasant to use. not always the same thing as
>     "more
>     usable"; it can certainly help win over users though, and make
>     using the
>     software more enjoyable.
>
>     > of "usability" or "cleanliness". I maintain that we CAN have a
>     featurefull
>     > and useful apps that look smooth, clean and gorgerous. It can be
>     done.
>
>     i agree. unfortunately the chances of it being accomplished fully are
>     diminished by the number of people who talk but can't/won't/don't
>     actually
>     help write the fixes. this is the biggest conundrum.
>
>     > > see ... if you feel that kde is resistant to "let's fix the
>     interfaces"
>     > > i'd like to know what communicates that and then hopefully fix
>     it. it may
>     > > be a real, valid issue within the project, if may be a matter
>     of public
>     > > perception, it may be a problem in communication, it may be
>     that we don't
>     > > have a properly visible means to bring in these contributions.
>     i could
>     > > guess, but only you know this answer when it comes to you and your
>     > > statement above.
>     >
>     > I'm afraid that it's nothing really tangible that I could point
>     with my
>     > finger and say "it's this thing here". It just seems to me that
>     KDE is
>     > somewhat conservative when it comes to design-changes.
>
>     mostly due to manpower. we generally spend a lot of effort
>     bringing something
>     functional to the table and that has traditionally left very few
>     hours for
>     working on the interfaces. more people working on that would help
>     immensely.
>
>     > KDE and some KDE-apps have a tendency to feel like they were....
>     > designed by a committee
>
>     this is a problem of success: as the project has grown larger, our
>     control
>     through maintainership hasn't tightened to help shape the growing
>     tide of
>     contributions.
>
>     > feature in there. Everyone is afraid to remove anything, because
>     someone
>     > put that particular feature there, and people are afraid that
>     they might
>     > feel hurt if "their" feature was removed.
>
>     at least for me, it has little to do with being afraid of hurting
>     the author's
>     feelings. my biggest problem is how many people bitch about every
>     fucking
>     change. i am personally fed up with that particular class of
>     ingrates who
>     employ "scream, cry and whine" reaction to changes, doubly so when
>     they are
>     users who contribute exactly 0 back and within a month or two are
>     just fine
>     with the change.
>
>     it wouldn't take so much bravery if people didn't bitch and moan
>     over every
>     attempted change. worst is when their pointless bitching is
>     ignored, they
>     turn around accuse us of "not listening to users". it wouldn't
>     take so much
>     bravery if more people were making changes and proving it could be
>     done. it
>     wouldn't take so much bravery if more people spent real coding
>     hours on these
>     issues with each other so it wasn't such a lone-wolf task.
>
>     ask the people who look after things like capitalization standards
>     or any of
>     the other similar issues. it's really pathetic. for every one
>     person fixing
>     things, we have 100 talking about fixing them and 1000 bitching
>     about how
>     they aren't fixed they way they want.
>
>     i still get emails and comments on my blog about icon zooming in
>     the panel.
>
>     no wonder so many people stop trying to change things: there is a
>     real
>     cultural problem amongst the hard core userbase. we've been
>     working hard to
>     fix cultural issues within the project, it'd be nice to see a
>     similar effort
>     from the users closest to the project as well. there is a reason
>     other
>     projects have just stopped listening altogether and decided to
>     make every
>     decision and centrally made policy decision, users be damned.
>
>     --
>     Aaron J. Seigo
>     GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
>     Full time KDE developer sponsored by Trolltech
>     (http://www.trolltech.com)
>
>
>     _______________________________________________
>     kde-quality mailing list
>     kde-quality at kde.org <mailto:kde-quality at kde.org>
>     https://mail.kde.org/mailman/listinfo/kde-quality
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> kde-quality mailing list
> kde-quality at kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>