Re: KDE and Gnome

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2003-08-26 at 11:19, Julien Olivier wrote:

> I know that. And that's why I say that the situation sucks. Maybe a
> solution for the future would be to find a way to have "special" buttons
> in GTK, QT etc... for cancel, apply and OK. Then we could configure the
> way we want QT or GTK to display those buttons.

That doesn't work.  We'd have to define "special" buttons for just about
every conceivable button.  Dialogs do a hell of a lot more than "OK" and
"Cancel" (which in many cases wouldn't even be HIG compliant, since OK
is a pretty damn useless name for a button - the HIG explains why).


> > * Windows doesn't always have a unified look: Norton AntiVirus, McAffee 
> > VirusScan, ZoneAlarm, Direct Connect, Office XP, Easy CD Creator, just to 
> > name a few. Not to mention all the amateur freeware apps out there that use 
> > flying colors and look totally inconsistent.
> 
> Well, having a themeing library should't prevent you from creating an
> app with a totally different look. But you should have the possibility
> to give a standard look to your app. Currently, when you create a GTK

You have that ability.  Use a real mainstream tookit and not a cracked
out niche/custom one.  If you use a weird toolkit, you must not have
cared about conformity.

> app, you have 2 possibilities: whether you create an app with the
> standard look or you create a skinnable app (like XMMS). You don't have

XMMS is dying, thankfully.  The sooner, the better.  The UI is worst
monstrosity I've seen in a long time.  I still can't figure out how half
of it works.

> more choice now. And the same goes for KDE: whether you use QT's look or
> you make your app skinnable. So having a themeing library wouldn't
> change anything, except that you can't choose between KDE look or GTK
> look (look which anyway depend on the QT and GTK themes the user use).
> And for third party toolkits (not GTK and not QT), having a themeing
> library would _allow_ them to get a standard look without _forcing_ them
> to do so.

If they cared about integrating w/ GNOME/KDE, why in the nine hells
would they use a niche/custom toolkit anyhow?  Mozilla's interface was a
mistake, one which has already been corrected w/ Galeon/Epiphany/Camino
and more for other platforms.  OpenOffice.org is another mistake, one
which is based mostly on the fact it's legacy code that can't be easily
converted.  Many other apps based on a Motif are also that way only due
to legacy code.  How would new theming methods help all these legacy
code anyhow?

Besides, as I mentioned in my other mail, standard look/feel falls aside
to other issues (like VFS) anhow.  The _only_ solution that's going to
solve all the integration problems is to switch to a single codebase,
like GNOME or KDE.  Otherwise, there will be differences.  And people
_want_ these differences.  Just because it's inconvenient to you doesn't
mean we should strip away the diversity people actively work to create.

> 
> So that would be a "win win" situation :)

No, it'd be a waste of time.  ;-)

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