A look at GNOME 2.14, comparison to KDE

Aaron J. Seigo aseigo at kde.org
Mon Feb 20 22:12:42 CET 2006


On Monday 20 February 2006 12:03, Janne Ojaniemi wrote:
> On Monday 20 February 2006 20:28, Aaron J. Seigo wrote:
> > On Monday 20 February 2006 10:54, Janne Ojaniemi wrote:
> > > http://kde.org/screenshots/images/3.4/snapshot06.png
> >
> > use a newer kde.
>
> I'm on 3.5.1, but KDE.org doesn't have screenshots of that, only 3.4. And
> I'm looking at Konqueror in 3.5.1 right now. And I don't really see any
> major difference between it and 3.4, as far as those UI-elements are
> concerned.

look closer, especially on the sidebar. the statusbar that was never used is 
gone, at least one set of bevels is gone .... as i said i didn't fix 
everything, but i did attack a few of the worst offenders.

> > some fixes are harder than others since we happen to have a more dynamic
> > set of technologies that actually do more. and yes, this has impacts on
> > the UI. they are not unfixable, but some require quite a bit of effort to
> > do right.
>
> I know that KDE "does more" than GNOME does. But the UI-elements I
> mentioned aren't really related to functionality as such.

you'd think that, but then you look at the code and start to understand how 
these things interact. the "9 menus versus 6" or the "there's a frame around 
the content area in konqueror" are, to pick just two very small examples, 
directly related to functionality-driven design in the code.

this is a reason, not an excuse. the design should not drive the interface to 
look bad, and it does not need to. but it is fair and rational to understand 
that it's not a matter of doing setFrameStyle(QFrame::None); in a few place 
and boingo! things are better.

> > as a counterballance point, i've heard gnome's "simplicity" described as
> > "hollow feeling" and "constructed" by IT managers in Very Large
> > Companies. it's not the One True Approach.
>
> Yes, we have heard the critique directed towards GNOME
> (*cough*Linus*cough*). But the things I mentioned ("smoothness" of the UI)
> aren't really about features and functionality as such (well, the menu's
> might be). I fail to see ow frames around content-area in Konqueror is an
> example of "advanced features" that KDE has while GNOME lacks it.

the frame is not an advanced feature (sheesh!), it's the result of the fact 
that when the component frameworks were designed and put together in kde 
little thought was put to "how do we manage frames around these components" 
and so it's trickier than necessary. getting rid of the bevel around the 
sidebar in the filedialog took the better part of a day due to how that was 
designed and written, for instance.

> that you are having a logical fallacy here. Just because Konqueror is a
> better filemanager than Nautilus is, does not mean that the sidebar-buttons
> are a better idea than Nautilus's implementation is. Just because Konqueror
> is overall better, does not mean that all the things in it are better ;).

of course. however, i fear you've missed the observation i was making: that 
going the route of "UI cleanliness" (ala GNOME) is not a valid primary goal 
and that looking at it from that perspective as the primary goal at this 
point will lead to heartache.

i've dealt with a few very stupid bug reports in the last week from people 
approaching things from the "UI cleanliness" viewpoint. the reports were 
stupid because they broke functionality that people rely on, yet the people 
didn't care because they are willing (foolishly, IMHO) to chase "UI 
cleanliness" above all else.

really, chasing GNOME in this regard is a fool's errand. if you want something 
to chase after, study Apple's designs. they are far superior in just about 
every way imaginable, to be honest.

> That said, it would be IMO even better, if the UI was less busy, and
> smoother.

of course. that's not contested. the means to get there is the question.

> > > A lot. I'm really looking forward to
> > > KDE4, and I really, really hope that it delivers on this front. I would
> > > guess that UI-changes like this are relatively easy to do, but for some
> > > reason I feel that changes like these are the ones that would face the
> > > most opposition...
> >
> > why?
>
> Bikeshed.

it's not a bikeshed at all.

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.

if we don't address such shortcomings, things will not improve. i'd like 
things to improve. therefore i'll ask again: what leads you to feel/believe 
that ui cleanups would face the most opposition from the kde project?

-- 
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20060220/6be3fd9e/attachment.pgp 


More information about the kde-quality mailing list