Re: Gtk3 and theming - a proposal (with code)

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

On Mon, Oct 13, 2008 at 5:48 PM, Alberto Ruiz <aruiz gnome org> wrote:

[...]

> I can't see why iteration over parents containers is needed in any of
> those cases with the proper tools in place. Our current idea is that
> containers push that context information into a the widget's context
> object before they delegate the rendering of their childs.
>
> Odd/even an order information is precisely one of those cases. As an
> example, figuring out if a tab of a notebook is the last one, is
> pretty much impossible at the moment even crowling unless you push
> that information from the notebook itself. Thing is, we have nowhere
> to push it at the moment.

This is unrelated to what I wrote. A notebook is a single widget,
hence it would be handled the "sub-controls" way.

Let me try another (hypothetical) example: you want to render the
h-button-box in a dialog window differently, say darker, analogous to
what's so popular with integrated window border / menu bar, e.g. [1].
You would need to push information all the way down from the toplevel
for being able to match the CSS selector "GtkDialog GtkHButtonBox {
... }" [2].

To support such arbitrary rules, giving the designers creative
freedom, every single widget would need full information about its
ancestors, and this isn't necessarily just static information. Imagine
you want the button box to change colour when the toplevel is focused
...

I hope this illustrates the implications of disallowing widget access.

[1] http://gnome-look.org/content/show.php/Shiki-Colors?content=86717
[2] Simplified for the sake of the example, would match any
GtkHButtonBox inside a GtkDialog, no matter which containers are "in
between".

- Rob