Re: KDE and Gnome



On Tue, 2003-08-26 at 10:34, Julien Olivier wrote:
> On Tue, 2003-08-26 at 15:14, Sean Middleditch wrote:

> > Well, there's a lot more to an interface than the color of its widgets. 
> > There is the whole feel/behaviour.  I can't stand using KDE apps (or
> > even Mozilla) because they act nothing like the other apps on my
> > desktop, even if I install a matching theme for them.
> 
> Sorry, I was talking of the look, not the feel.

My point was, obsessing over look is completely pointless.  It's
worthless next to feel, which is the real usability barrier.

> 
> > Buttons are in
> > different orders in dialogs.
> 
> Well, the situation kinda sucks. Why can't we find a consensus on this
> problem ?

I doubt it.  Many people hate the GNOME ordering.  I personally love it,
since it honestly does work better.  I almost never have to aim for a
button not in the bottom right corner, which was (I believe) a reason
for the new ordering design.

> 
> >   Configuration panels are huge messes of
> > useless crap I can't find my way thru.  Widgets are laid out with no
> > thought to organization or cleanliness.  etc.  Even a good deal of GTK
> > apps I can't stand to use because the UI is complete and utter crack. 
> > (like gSynaptic.)
> > 
> 
> That's a totally different problem because this lack of organizatio is
> not a direct consequence of the usage of one toolkit. It's simply a bad
> design and it can happen in GTK apps as well as QT apps, as you said.

Right.  Unification of anything isn't going to fix this, is my point.

> 
> > All this effort to make unified themes, or even use a single toolkit,
> > isn't going to fix the above.  The only way to fix it would be convince
> > all developers on a single UI design philosophy, which is impossible. 
> > Not to mention there will always be developers who try to do completely
> > insane and pointless things like the Mozilla cross platform UI, where it
> > fits into one platform (Windows) and feels totally alien on others
> > (GNOME, OS X, etc.)
> > 
> 
> In my opinion, there should be a way to make toolkit _look_ the same for
> the following reason:
> 
> I, as a developer, don't want to choose a toolkit because of its look. I
> want to choose a toolkit because it's the best trchnology. And if I
> choose QT over GTK (for example), and respect GNOME's HIG, I'd like my
> app not to look too much of a stranger in GNOME. And that can be
> achieved by unifying the "look" and standardizing the way the "feel" is
> defined.

If you choose a toolkit due to look, that is your own problem.  Both of
the major toolkits are heavily themable.  Making any decision based on
look is so foolish I can't even stress it enough.

So far as feel, it isn't going to be unified too much.  GNOME and KDE
have different feels because the developers/users _want_ different
feels.  I hate the feel and behaviour of KDE.  Others hate GNOME. 
Unification would just piss off both such camps.

> 
> > The best solution for unified look is to just use GNOME apps.  Don't
> > like how Mozilla looks?  Then why are you using it instead of
> > Epiphany/Galeon?  OpenOffice too Windows-ish for you?  Try
> > Abiword/Gnumeric.
> > 
> 
> OK, that means that I can't create presentations because I don't like
> OOO's look as GNOME doesn't have a presentation program. And that also
> means that, for a developer, it's impossible to create an app that will
> please everybody. Or you have to create a KDE frontend, a GNOME frontend
> and a MOTIF frontend. That sucks...

Ya, it does.  Those front-ends are all different for a reason tho.  if
you don't care about people using KDE, don't waste time on a KDE
front-end.  If you do, then you have to please the KDE people, who
_want_ a different interface than that which GNOME users would enjoy
best.

Forcing un-optimal compromise on users and developers because you want
to please everyone and not put forth the effort to do so seems rather
selfish. ;-)

> 
> > The only other solid option is to do what Abiword did - separate the app
> > core and GUI layer, so you can implement different interfaces (GNOME,
> > Windows, OS X, KDE, whatever).  I'm very sure KDE could have a native
> > Abiword interface if anyone cared enough to code one.
> > 
> 
> That would be a solution but don't expect every programmer in the world
> to start separating the app core from the GUI. That would be great but
> that's not the case.

Just like we don't expect every desktop to magically start using
groupthink and agree on a set of interface standards which are largely
up to taste and philosophy, something it would be tyrannical to try to
"standardize" and enforce.

> 
> > We'll never magically get all apps to integrate, tho.  There will always
> > be people like the Mozilla developers, or people who purposefully pick
> > odd-ball non-mainstream toolkits because they don't care about or
> > actively dislike the modern desktops.  Let's accept that and move on. 
> > ;-)
> > 
> 
> You're right ! You'll never have one and only one toolkit. And that's
> why we should try to find good ways to help apps integrate well with
> other toolkits. It's probably never going to be 100% perfect but that's
> not a reason to give up, especially when there _are_ solutions.

These toolkits often exist specifically to avoid the "standard" of gtk
or qt.  The others are inconsequential.  If developers choose to avoid
GTK and Qt, that's their problem.  They lost a lot more than just the
look/feek by avoiding the rest of the GNOME/KDE libraries, and those
apps should probably be replaced with native, more powerful apps
anyhow.  (For example, GTK apps without gnome-vfs support are a huge
pain, since I often access files on network file systems thru gnome-vfs
- apps that can't do this are a hindrance to me, and I don't care what
they look like, since they aren't very usable.)  Integration has to
happen at a far lower level than the method used to render a button, or
even where that button is.  The proper solution is to get people to stop
using oddball niche toolkits or coding their own, and start using the
more powerful and already standard libraries and kits provided by the
desktops (KDE and GNOME).

-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]