Desktop Theme Spec

Rodney Dawes dobey.pwns at gmail.com
Sun Apr 20 13:10:01 PDT 2008


On Mon, 2008-04-21 at 03:09 +0800, 洪任諭 wrote:
> 2008/4/21, dan_500 at web.de <dan_500 at web.de>:
> > 洪任諭 wrote:
> >
> > > We should have only one set of common theming API for all toolkits.
> > > Then some backends for every toolkits should be created by the developers
> > > who master these toolkits.
> > >
> > >
> >  When you have a common theming API, you have a common theme, too, isn't it?
> > Is a common API the only way? What do you mean with API? An API in hundert
> > veriants of languages? An common daemon? Everthing is bad. So just use an
> > comman theme format.
> >
> We are talking about totally different things.
> Having common theme "format" doesn't give you common themes since
> most of what you saw in every themes are drawn with code, not defined by files.

If two pieces of code draw the same format differently, there is a bug
somewhere. That's like saying KDE and GNOME are allowed to render SVG,
HTML, PNG, or any other displayable format, differently, and it's OK.
But we all know that's not how things work, and it isn't true.

> Having common format to define colors / pictures / fonts is far from
> having common themes.
> The underlying theme engines need to be re-designed.

They need to be destroyed. Theme engines are one of the worst things we
have. It's very hard for artists to design a theme, when they don't know
how to code, if they have to write an engine.

> If you don't understand what I said, maybe you can take a look at the
> source code
> of some gtk+ theme engines and some Qt ones. Then you'll know why I said this.

I don't understand what you've said, and I've written a theme engine,
and worked on several others.

SVG is almost what we need for a common theme format. It's a bit off
from what we need, but it's quite close. What we need is something
similar to SVG, but where x/y/width/height/etc... are dynamic, and
specified at render time, so that we can have truly scalable art in
our themes, and we can eliminate the need for writing code to theme
toolkits. 

If you really just want a cross-toolkit API for theme engines though,
perhaps you should take a look at the metatheme project. I think it
is/was hosted at http://metatheme.cx. I don't know what is up with it,
but that is exactly what the project was working on.

Of course, either of these solutions have the drawback of not being able
to make significant changes to existing widget behavior/look in the
theme, as you can now with the toolkit-specific engines, by manipulating
widgets directly.

-- dobey




More information about the xdg mailing list