Re: KDE and Gnome

[Julien Olivier <julo altern org>]

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

Yes, that's a solution but it needs twice as much work now and maybe
even more if, one day, another toolkit becomes very popular.

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

I think you misunderstood me. I was talking about bitmap themes, not
dynamic engines like liquid. Of course using only bitmap themes would
reduce the possibilities...

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

I agree with you. But my point was that if I want to create an app using
QT and make it work well in GNOME (using gnome technology where
possible), my app will have no way to also look like a GNOME app. That
means that I'll be stuck using GTK (which may also be a good thing) if I
want to write a app integrated in GNOME. More over, with the work being
done in freedesktop.org, KDE apps and GNOME apps should ultimately feel
the same whichever technology they use (in a far future of course). So,
it could be great if they also looked the same natively.

> there you go with that "native linux app" stuff again.  Drop that idea;

I recon that using the "native linux app" term is unappropriate. I
should have said "native X11 app".

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

Well, what about OpenOffice ? Which look should it have ? Or maybe
you'll tell me that OpenOffice shouldn't be used at all because it
doesn't belong to any desktop ?

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

That's what I did. And freedesktop's philosophy is not "each app should
run on its own desktop". It's more "you should be able to use any
toolkit to wirte apps that look/feel native on any 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!
> 

Of course ! That would be great. I don't say that it's needed but if you
could find a solution to make GTK and QT apps to look like Aqua when run
on MacOSX, that would be great, wouldn't it ?

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

If some toolkits don't want to use bitmap widgets, that's a problem.
This solution would of course only work for _bitmap_ themes, which are
managed by both QT and GTK currently. Another solution would be to use
SVG themes only but, of course, that would have a negative impact on
performance.

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

Well, if it's really impossible, let's just forget it. The thing is
that, after discussing with one of GTK's main developers, he told me
that sharing bitmap themes between different toolkits (including QT and
GTK) was possible and only needed someone to code it.