Re: GUADEC Theming API meeting minutes

["Robert Staudinger" <robert staudinger gmail com>]

On Thu, Jul 17, 2008 at 1:19 PM, Garrett LeSage <garrettl gmail com> wrote:
> Hey everyone,
>
> I'm really excited about being able to use CSS to define the way a GTK+
> theme looks.  I've had my hand in making GTK+ themes in the past and know
> CSS pretty well, so this is a perfect intersection for people like me.  (:
>
> Sorry I couldn't make it out to GUADEC to talk with you all about this in
> person, but hopefully I can provide some help through emails and possibly on
> IRC, etc.

That'd be much appreciated. For the record, I was not at there either
and this effort predates the meeting. It's only by incident that I've
been starting do discuss this in #gnome-art recently.

> A quick list of things that I would really like
>
> keep as close to the CSS spec as possible (especially pay attention to CSS3,
> as it has lots of useful things)

This is Teh Plan.

> it is okay to use CSS extensions where CSS has a few gaps, especially since
> this is theming widgets, not web pages (although try to keep them down to a
> minimum)... something like: -theme-appearance: button; (similar to
> -moz-appearance [1])

I am not sure how this relates to what I'm doing. My engine does not
implement any kind of styling, everything that should be drawn has to
be specified in CSS and matched through selectors and pseudo classes,
so it shows up when appropriate.

> make a "page" that shows off all the "widgets", as well as common
> combinations (like nesting, etc.), and make it easy to "reload"... this
> doesn't really have to be a page, but something like this is a really nice
> thing when styling using CSS for a web page

Do you mean something like The Widget Factory, possibly enhanced?

> leave the padding up to the CSS style, based on relationships of widgets
> start from scratch, with no appearance defined whatsoever, but have a common
> styling that themes inherit from so that they can instantly define buttons,
> etc.

I am not sure specifying paddings is possible without changing gtk itself.

> support as many useful selectors & pseudo-classes as possible

Please look at
http://bzr-playground.gnome.org/~robsta/gtk-css-engine/annotate/21?file_id=readme-20080630152523-k74ehpkuf0lttzfl-7
"State" will probably be implemented as pseudo-classes (e.g.
GtkButton:prelight { ... } )

> make sure cascading applies

Tell me if I got the idea of cascading right, here is an example
("box" is the primitive used to draw GtkButton-s):

box {
    border: 1px solid black;
}

GtkButton {
    background-color: white;
    border-radius: 2px;
}

GtkButton:prelight {
    background-color: yellow;
}

GtkButton[has-default=true] {
    border: 2px solid red;
}

Now a prelit GtkButton that is default for a dialog would accumulate
all the properties of the above example.

> take advantage of the ability to use multiple classes on an element...
>
> HTML: <a class="foo bar baz">
> CSS: foo {}, bar {}, and baz {} would all apply to the above HTML

I am not sure how that maps to gtk widgets. Maybe one could give a
widget a "name" property of "foo bar baz" and have the engine apply
the matching styles.

> applications should have a top-level id, so someone could do something like
> this:
>
> #gimp #toolbox button { -theme-appearance: button-small; border: none; }
> #gimp #toolbox button:selected { background-color: Highlight; color:
> HilightText; }
> #gimp #toolbox button:hover:selected { background-color: HighlightHover;
> color: HilightTextHover; }
> (I'm adding these extra states to show how things would work in other ways
> too)

I've been pondering this idea, maybe it should be $gimp instead of
#gimp though, to have a clear distinction of what is what?
We should probably match on what g_get_prgname() returns.

> support CSS variables [2]

Interesting, will look into that. Named colours could be predefined variables.

> have an introspection utility like Firebug so that theme authors and
> application developers can easily click widgets and explore an application
> by browsing around something like a DOM tree, with widget properties and
> such... once upon a time there was something that was sort of like this
> (called GLE [3]), which sort of worked, and then was not maintained and
> shortly bitrotted

Your wishlist is long.
Maybe this is just a quick hack for someone with a11y fu though.

> if this could be made at a lower-level than GTK+ itself, it would be nice...
> then GTK+ could call on this library to do the widget rendering, but so
> could Mozilla, OOo, and even Qt (which does this for non-UNIXy platforms
> like Windows and OS X already)... also, this might make adoption for things
> like custom Mono widgets (as in Banshee), Mono's WinForms, Wine, and even
> currently not-really-themable toolkits (Tk, Lesstif, etc.) easily possible

The drawing code is independent from the engine, I'm building a
library preliminarily named the "css box drawing library". For now
it's located in the same source tree, albeit different directories.

> References
>
> -moz-appearance: http://developer.mozilla.org/en/docs/CSS:-moz-appearance
> CSS variables: http://disruptive-innovations.com/zoo/cssvariables/
> GLE: http://testbit.eu/~timj/historic/gle/
>
> Thanks for reading!

Thanks for weighing in.
- Rob