Re: KDE and Gnome

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2003-08-26 at 12:52, Julien Olivier wrote:
> On Tue, 2003-08-26 at 17:23, Sean Middleditch wrote:

> > Redhat and Mandrake both solve this.  I'm sure SuSE will too, if they
> > haven't already.  Other distros may or may not care enough to use a
> > unified theme; if they don't, they are the wrong distro to use with
> > people who care about this stuff.
> > 
> 
> I'm not sure letting distributions fix problems is a good idea... but I
> agree that using a "fake" unified theme can be seen as a solution.

Lots of problems are distro problems.  ;-)

> 
> > > 
> > > More over, if someone uses GNOME and changes its theme, it just changes
> > > GTK theme. So, even if his GTK theme used to look like his QT theme, it
> > > won't be the case anymore after changing his GTK theme.
> > 
> > This is teeny bug, and doesn't need a massive toolkit purging or theme
> > redesign to fix... just write a little spec for picking theme name
> > (using XSETTINGS, perhaps) and the likely few lines of code needed for
> > it, and you're done.
> > 
> 
> No it's not a bug ! The problem is that there are about only 3 unified
> themes: Galaxy, Bluecurve and [K/G]eramik. That means that if you want
> to fix this "bug", you have to remove every other themes from the GTK
> and QT theme dialog and display only thise 3 themes. Then you can make a
> script that synchronizes GTK and QT themes.

Or just start making more syncronized themes.  Look at the "metatheme"
stuff GNOME has - GTK, Metacity, Icons, etc. are all different theme
systems, yet they can be bundled together and set together.  Just add
KDE themes to the mix.

> 
> Then, if you want to create a theme for Linux, you have to create a GTK1
> theme, a GTK2 theme and a QT3 theme instead of simply creating one
> theme.

Well, yes, they are totally different toolkits that act completely
different.  A unified theme engine isn't going to work.  GTK doesn't
just say "draw button here" that a theme library could pick up.  GTK
draws w/ GDK, which abstracts X11/FB/Windows/etc.  So a theme library
would have to sit between GTK and GDK which, oh my gosh, is exactly what
the GTK theme system does.  Now how do you integrate that into Qt...?

The closest thing I think you could do is write a couple some theme
engines for GTK1/GTK2/KDE that use a common set of config options (maybe
something like ~/.unified-theme-rc) to do the rendering.  The actual
toolkits aren't going to ever use a unified library, but you might be
able to pull off that kind of unified theme.  That's exactly what Redhat
did with Bluecurve - you'd just make it so the themes would be
configurable.

But when it comes to good engines, that drastically alter how the
widgets are rendered, or pull off special optimization tricks like the
KDE Liquid theme, there just isn't any way a theme library would work. 
Not when you need to maintain cross platform functionality.  (Qt and GTK
both work on a wide array of platforms.)

> 
> > Let's not fix the loose nail with bulldozer.
> > 
> 
> OK, but at least let's try to fix it properly ;)

Agreed.  ;-)


> > Right.  Just like you can not use GTK/Qt if you want to.  It looks and
> > acts different because _they wanted it to_.  You can offer all the
> > unification you want, but if people don't want to use it, it's not going
> > help any.
> > 
> 
> I agree. But the problem is that, currently, even if you _want_ to make
> your app look like other apps, you can't. Because you can't be sure that
> your users' GTK and QT themes match. So you have to know which desktop
> they run.

I still don't think GTK/Qt themes matching even matters.  Aside from the
other far more important issues, this is so minor...  I don't want an
app that looks GNOMEish but can't use the VFS, doesn't use GNOME layout
principles, doesnt' integrate into the rest of the system, etc.  I don't
want somethign like Mozilla that can look like anything I want (it even
imports GTK themes to an extent) but still feels wholly alien.  Just
write your app for GNOME and be done with it.

> > 
> > Why make a new toolkit, other than to not look/act like what we already
> > have?
> > 
> 
> Maybe simply because you think GTK or QT are bad from a technical point
> of view ? Maybe someone wants to create a very fast/light toolkit but
> still wants to have it look like a native Linux app.

there you go with that "native linux app" stuff again.  Drop that idea;
there is no "Linux" look.  There is a GNOME look.  There is a KDE look. 
_those_ are the desktop platforms; the system underneath is completely
and absolutely meaningless in regards to normal user apps.  If KDE and
GNOME look different, _fine_, they are two very different systems.

There is work on integrating them, but so far, that work is on stuff
that actually matters - check the freedesktop.org site.

> 
> > > look ? MacOSX' look ? How do you define what is Linux' default look ?
> > 
> > Linux doesn't have a default look.  Linux is a kernel.  GNOME is a
> > desktop - you make an app to work with the GNOME desktop.  Make the app
> > be a GNOME app or not.
> > 
> 
> I know that Linux is jut a kernel. s/linux/X11 everywhere if you want.
> That doesn't change the problem, which is that on X11, you have to
> choose a desktop (GNOME or KDE) but you can run apps made in any toolkit
> on this desktop. That's why toolkits should try to look the same on a
> given desktop.

Right.  So, in that case, GNOME and KDE absolutely must look and act
like Aqua, since I can run GNOME on OS X w/ X11.  Glad we have that
solved!


> > And back to your theming library, what is it going to solve?  What?  You
> > can't unify anything except in the toolkit itself - the whole method
> > used to draw widgets varies between toolkits.  They vary based on
> > backend (X, Cairo, FB, etc.).  It's not feasible.
> > 
> 
> Of course it's feasible. All the library would return would be an array
> of pixels defined by theyr RGB value (a pixmap). Then eahc toolkit would
> draw it on its widget they way it wants.

You are so over-simplifying it's not even funny.  What happens when
toolkits move to Cairo for rendering?  What happens when toolkits want
to accelerate rendering beyond blitting some pre-made cheesy pixmap? 
Most theme engines do a lot of very customized drawing with no pixmaps
in sight, and that's a good thing.


> > I.e., just making KDE and GNOME sync themes, instead of trying to
> > revolutionize the toolkit space that no one else has ever been able to
> > do.  ;-)
> > 
> 
> Well, sorry talented people for spamming you with my uninformed
> guessing. Just ignore me...

Not what I meant; sorry if I offended you.  Just saying, it's pretty
clear (to me, at least) that magic unification with a little theme
library is all but impossible.

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