Re: Theming API hackfest: last call

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

Cheers,

behdad

> Internally a GtkButton is drawn using gtk_paint_box(), so both the
> "primitive style" and the "widget style" have to be combined. The CSS
> engine does so by merging the primitive style into the widget style
> with a lowered priority, see also [1]. Things are not quite finished
> for composite widgets like GtkComboBox, but there is a plan.
> 
> It soon became apparent that CSS drawing capability wrapped into a
> simple API might be of use for other cairo-based applications as well,
> so with some support from Carl Worth I spun that part off to fd.o
> after the recent 0.2 release. Currently I'm focusing on the libccss
> API, feedback from Intel's Robert Bragg and Thomas Wood has been very
> valuable. After that I'll try to focus on the engine again, mostly the
> support for composite widgets mentioned above.
> 
> I'll also be looking into setting style parameters from CSS, probably
> something like "GtkButton { gtk: child-displacement-x(1); }" or
> "GtkButton { gtk-child-displacement-x: 1; }".
> 
> Finally, regarding the SVG theming efforts that are floating around
> [2, 3], I think that CSS and SVG are mostly orthogonal rather than
> competing with each other. SVG is great for graphics, and CSS is made
> for things like expressing that the GtkButton instance inside a
> GtkTreeView should be drawn as a column header.
> 
> [1] http://www.w3.org/TR/CSS21/cascade.html#specificity
> [2] http://groups.google.com/group/manju-project
> [3] http://mail.gnome.org/archives/gnome-themes-list/2008-October/msg00001.html
> 
> Hope that helps a bit, I'd be happy to answer more specific questions,
> or just find me on gimpnet.
> 
> - Rob
>