A look at GNOME 2.14, comparison to KDE

Janne Ojaniemi janne.ojaniemi at nbl.fi
Tue Feb 21 20:06:16 CET 2006


On Monday 20 February 2006 23:12, Aaron J. Seigo wrote:
> 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.

And I thank you for that :).

> 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.

But couldn't the same functionality be achieved without those frames (menu's 
might be a different matter, however)? The content-area could be separated 
from the window-background without having to resort to grey lines 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.

> 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.

I trust that these things are being looked at in KDE4 :)?

> 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.

But if we can choose between functional and useful filemanager/web-browser 
that looks good and functional and useful filemanager/web-browser that 
doesn't look as good, surely the former is the app of choice, as opposed to 
the latter? I think that we can have the former. We can have the cake and eat 
it too :). I think that all else being equal, an app that looks good is 
inherintly more usable than an app that doesn't look good.

> 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.

My intention is not to sacrifice features and/or functionality on the altar 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.

> 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.

I have done that. Well, my "studies" have been limited to using OS X 
occasionally, and comparing and contrasting it with KDE.

> 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. Yes, that conservatism has it's 
benefits. KDE and some KDE-apps have a tendency to feel like they were.... 
designed by a committee. Everyone has an idea of what should be in there, and 
everyone then proceeds to add their favourite 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. And the end-result looks a bit like mish-mash. Note: things are not 
as bad as they sound from my above comments. And I don't know that is the 
above observation correct, but it's a gut feeling I have. If the observation 
is not correct, then this is a case of communication/image-problem.

Now, I don't know what is different in GNOME. It might be that they made a 
conscious decision to move the project to a certain direction, whereas KDE 
more like evolves towards certain direction.

I hope that I'm making at least some sense here :)


More information about the kde-quality mailing list