Re: Theming API hackfest: last call

[Christian Dywan <christian imendio com>]

Am Tue, 14 Oct 2008 17:44:06 -0400
schrieb Behdad Esfahbod <behdad behdad org>:

> Robert Staudinger wrote:
> > On Fri, Oct 10, 2008 at 3:36 AM, Behdad Esfahbod
> > <behdad behdad org> wrote:
> > 
> > [...]
> > 
> >> Hi Rob,
> >>
> >> I got to know about work you are doing by crossing over your fd.o
> >> account request.  I thought to myself: "wow, this is so cool...
> >> why didn't I hear about this stuff before?"  I think a good number
> >> of GNOME/GTK+ developers are in that boat too.  So, why don't you
> >> tell us some more about what you've been doing and what your
> >> future plans are?  Here on the list I mean.
> > 
> > Sure.
> 
> Thanks for the overview.  I have no experience in themeing so I can
> just offer side bikeshedding comments.
> 
> > It was some 2 years ago when I first toyed with CSS, gtk and
> > engines, but quickly lost interest because trying to parse
> > gtkrc-embedded CSS with GScanner was too much legwork. This summer
> > I looked at the code again but only after taking the time to read
> > up on libcroco usage. Basically, why did you not hear about it,
> > well, it took some time to get from the "it kinda does something"
> > of the early prototypes to a better understanding of the issues
> > involved. I am confident that the upcoming 0.3 release will be more
> > suited to be shown off.
> > 
> > The main items of experimentation have been the intersection of
> > primitive- and widget-theming and the libccss API.
> > 
> > By "primitive theming" I am referring to direct influence on drawing
> > function calls. If you write "box { background: red; }" in your CSS,
> > the visual result of gtk_paint_box() calls will be affected.
> > 
> > "Widget-theming" on the other hand is applied to gtk's type names,
> > like e.g. the CSS statement "GtkButton { border: 1px solid
> > black; }".
> 
> Shouldn't the class-specific ones use the css class modifier?  That
> is, ".GtkButton"?
> 
> Another relevant idea is that sophisticated CSS matching rules may
> help theming complex widgets without requiring them to expose their
> internal structure.  For example, ".GTKTreeView>.GTKButton" will
> match a GTKButton that has a GTKTreeView parent.

The way I read that, I think you are contridicting yourself. You are
saying 'without requiring [...] to expose their internal structure' but
at the same time suggesting themeing based on exact knowledge of the
hierarchy, which *is* in implementation detail and nothing else.

A real help would be if it was more like

.GtkTreeView .column-header { }

Or even better

.tree-view .column-header {}

Which would enable you to actually theme without knowing how the widget
is implemented, and in the second case even what particular class it
is. For the sake of the example, those identifiers could be widget
names.

I imagine there could be a straightforward table of supported widget
names as part of the reference documentation.

ciao,
    Christian