Re: Theming API Hackfest

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

On Wed, Sep 3, 2008 at 1:25 PM, Alberto Ruiz <aruiz gnome org> wrote:

[...]

>> Thinking again, most of the detail strings are actually redundant if
>> the engine is allowed to know what kind of widget is drawn.
>
> No, they are not always redundant, and the engine is allowed actually.

I did not say /all/ detail strings are redundant, but if the redundant
ones were removed it might be easier to find a solution avoiding the
quirks of a string API for the remaining ones.

Also I thought this whole thread was about theming in gtk3, for which
it was proposed that direct access to widgets should be revoked. In
gtk2 it's a different story, as we all know ...

> That approach (which is quite used), suddenly ties engines to
> implementation details of widgets, denying developers to change those
> implementations since the theming API is a public interface that
> people consume to make third party engines.
>
> Now, the idea discussed is to solve that by allowing widgets to give
> more information without allowing engines to crawl up over the
> widget's parents and stuff like that.

My point is that permitting to traverse the widget tree allows for
simpler and more generic code in gtk proper. gtk_widget_get_parent()
is already there, nothing new required. See below for details.

[...]

> It is actually a quite valuable work that people start playing with
> more usable engines for artists and i'm pretty sure as soon the idea
> progress you would be able to give us a quite valuable feedback.
>
>> Generally, instead of passing more context information to the engine
>> as it is being discussed, I'd rather provide hooks to the style
>> matching subsystem for widget implementers and look mimicking. This is
>> also the approach taken in the CSS engine.
>
> You mean hooks as in "widget: If I match this style matching
> expression I send this event" or something like that?
>
> Could you elaborate a little bit on how this could be implemented and
> how much effort for a widget implementer would take to do it properly?

The CSS engine fills a vtable, so the selection engine can traverse
the widget hierarchy without actually knowing anything about widgets.
Look for `ccd_node_class_t' in the file linked below. Lookalike
toolkits could fill the vtable with their own functions, thus being
able to fake entire widget hierarchies without creating any gtk widget
offscreen to have it drawn correctly.

http://bzr-playground.gnome.org/~robsta/gtk-css-engine/annotate/54?file_id=ccdnode.h-20080812073847-d210lox1qul689g2-44