Re: KDE and Gnome

[Julien Olivier <julo altern org>]

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

I know that it's the current status of application development on X11.
But I was hoping that things might change thanks to freedesktop guys.

What I mean is that I expect QT apps to be able (one day) to work with
GNOME apps without having to use gnome-vfs directly. To take a concrete
example, a few months ago if you wanted to put your app's tray icon in
GNOME's panel, it wouldn't have worked in KDE's panel. Now it's solved.
So you can make a QT app that will display a tray icon in GNOME's panel.
And the same could be right for URIs one day... 

> 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!")
> 

I know that some KDE advocates can have very strange reactions
sometimes. But what counts is not that they use libXML2, it's that XML
is a standard ! And currently there is no standard for the look of
widgets.

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

Yes, and you might be right, but maybe there is a possibility anyway :)

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

Of course, but in fact the idea was to make a GTK engine that would use
this library and a QT style that would use this library. That means that
if you don't use one of those engines, you don't need this library. For
example, you could still use bluecurve engine and wouldn't need this
library.

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

What you write is true for GNOME and KDE but it's still false for Java,
OpenOffice and Wine for example, which are very widely used on Linux.

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

And that's what is wrong. You shouldn't have to know which desktop your
potential users run when you develop an application. I mean, that's not
like if 90% of users preferred GNOME. It's about a 50/50 situation...
 
> > 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.  ;-)
> 

The problem is when you want to follow GNOME's philosophy but don't want
to use GTK for any reason...

> 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.  ~,^

Well, this discussion won't go anywhere because you think each desktop
should be totally seperated from the other desktop. That's a possible
way to see things and I respect that. That's just not the way I see
things. My philosophy is that we should try to virtualize the look and
feel of applications, whichever toolkit they use. But I also know it's
an almost impossible mission.