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

["Alberto Ruiz" <aruiz gnome org>]

2008/10/13 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.

Sure, gotcha, we have taken that scenarios into account already,
however, this is getting a bit off topic since what we were supposed
to discuss here was CSS. I just wanted to raise the point that the
theming API is not that versatil, and abusing it doesn't really mean
it's flexible.

Back to the topic of CSS as replacement of GtkRC files.

I'm quite interested in knowing what's the plan reagarding style
properties names. At the moment, xthickness/ythickness is used for
different things depending on the widget. I'd love to see a plan on
using the appropiate CSS semantics for each use case. Do you have any
plans to write down the matches for each use to be replaced for more
CSS familiar names such as padding/border/margin?


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



-- 
Un saludo,
Alberto Ruiz