Re: KDE and Gnome

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2003-08-26 at 12:34, Julien Olivier wrote:
> On Tue, 2003-08-26 at 16:37, Sean Middleditch wrote:

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

Using Qt for a GNOME app is wrong.  For starts, your app wouldn't even
run on a lot of GNOME desktops, since Qt isn't installed.  Second, a
GNOME app is more than just a GUI.  You need the VFS, configuration,
desktop integration, etc. - you simply can't get that without the GNOME
libs, which you can't really use effectively with Qt.  If you want to
make a GNOME app, use the GNOME libraries.  Why should anyone support a
sick endeavor to use an alien toolkit to write a GTK-like app?  (Since
that's all it'd be, not a GNOME app.)

As I've said before, the toolkit is just a small piece of the puzzle. 
Even if you have a Qt app that has a GNOME theme and you laid out the
widgets according to the HIG, it will _not_ be a GNOME app.  You know
what the solution to that is?  Use the GNOME libs.  Which will also
solve the look problem.

> 
> 
> Feel will be unified if I choose to make my QT app feel like a GNOME
> one. As you said, it's all about the developer, which I am. I don't care
> about other KDE apps. What I want is have the liberty to choose my own
> toolkit, even if I want my app to integrate with GNOME.
> 
> > Unification would just piss off both such camps.
> 
> 
> In fact, using a themeing library to render widgets wouldn't piss any
> camp because that wouldn't change anything for any camp. Each toolkit
> would simply have to port their themes to this library.

You don't know the KDE camp very well, do you?  ;-)  ("libxml2 was
written by a GNOME guy, who cares if it's the best XML lib, let's write
our own!")

Besides, I've already explained the technical reasons a theme library
isn't feasible.  ;-)

The theme library would rather irritate me tho when it came to being
cross platform, running on non-X11 systems, performance, etc.

> > 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. ;-)
> > 
> 
> Just explain me why if I want to create a windows app I don't have to
> take care of the toolkit I use while I have to do so on Linux. Don't you
> see a problem here ?

No, because Linux isn't a desktop and Windows is.  I don't have to take
care of the toolkit I use on GNOME tho, since there's only GTK and the
wrappers for it.  It's pretty unified in KDE-land too, since that's all
Qt based.  If you're coding for GNOME, you code using GNOME libraries. 
If coding for KDE, you use KDE libraries.  It's pretty simple and hard
to get confused on this topic.  Linux isn't the desktop, KDE/GNOME are. 
X11 can run on Windows - does that mean all X11 apps had best look like
Windows apps?  They might not fit in when I run X on Windows if they
don't!

Of course, you _do_ need to be careful of toolkit in Windows.  You can
look at an app and easily tell which toolkit it used - MS', Borland's,
GTK, Qt, Mozilla, StarOffice, etc.  They all have little differences,
sometimes large differences in behaviour.  Not to mention with a lack of
a unified UI standard (that developers actually use), you generally need
training (or lots of experimentation time) for every new Windows app you
use.

> > 
> > 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.
> > 
> 
> When I say standardize, I don't mean enforcing. For example, if each
> toolkit _could_ use a themeing library to render their widgets, that
> wouldn't force them to change their look as the look would be ultimately
> defined by the theme used with this themeing library. So, for example,
> QT would use the themeing library and KDE would have a keramik theme for
> this library. As a result, that wouldn't change anything for KDE users
> except that if a KDE users opens a GTK app in KDE, his GTK app would use
> the keramik theme and, thus, have the same look as his KDE apps. Of
> course, each desktop (GNOME, KDE) could still have a default theme on
> his own. But this theme would apply to "foreign" pps too.

Ya, we've covered this library before.  ;-)

> > 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.
> 
> OK, but what is a "native" linux app ? Are GTK apps native or is it QT
> apps that are native ?

What is a native linux app?  Anything using the core Linux API, which
would be a rather uninteresting console app.  GTK apps aren't native to
anything, altho GNOME apps (which have many libraries besides just GTK)
are native to GNOME of course.  Same goes with Qt - a Qt app is a lot
different than a KDE app.  Not only do some appearance issues change
when only using Qt, but Qt apps aren't fully part of the KDE desktop.

Toolkit doesn't matter, the entirely of the libraries used does, and
those mandate toolkit.  To get a GNOME app, you must use the GNOME libs,
and thus you must use GTK.

> 
> >   (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).
> 
> As long as we have more than 1 "native" toolkit, the only solution is
> standardization. Windows doesn't have only 1 toolkit. However you hardly
> have interoperability problems (except look clashes sometimes). Anyway,
> that's off topic as the topic was "look".

"You have unsaved documents.  Save before quitting?" [Yes] [No] [Cancel]
"You have not saved your documents." [Quit] [Cancel] [Save and Quit]

Those look _completely_ different.  Very different semantics.  Theme
doesn't solve that problem, tho.  What does?  Interface design and
philosophy.  No library is going to unify that.  The buttons might be
drawn the same, but you quickly notice the different layouts.  Imagine
the KDE user clicking [Quit] because they're used to always hitting the
far left button without reading it.  If nothing else, a different look
might have at least alerted them they were in alien UI territory.  ;-)

If you want GNOME, design for GNOME, and completely forget KDE.  Or vice
versa.  They aren't two co-existent systems on the "Linux desktop", they
are two totally separate desktops.  If you're writing apps for a "Linux
desktop", you're writing apps for something that doesn't exist.  ;-) 
You're just going to end up with a look _and_ feel abomination like
Mozilla.  ~,^

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