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 3:06 PM, Alberto Ruiz <aruiz gnome org> wrote:
>
> [...]
>
>> And if you allow engines to access widgets, widgets can only do things
>> that have been thought of /before/, which is a problem with worst
>> consequences. Plus, you can easily add that information on the widget
>> renderer function with a GtkStyle replacement.
>>
>> The CSS engine would not have been possible like that, because the
>> theming api doesn't provide any other alternative. That's exactly why
>> it should be fixed.
>>
>>> If the nesting of a composite widget is part of the stable gtk API,
>>
>> Is it? A widget implementation is not part of the stable gtk api at
>> all, that's one of the reasons sealing is so important, letting people
>> access to the private members is been preventing Gtk+ from substantial
>> changes and improvements.
>
> This is not the point. Engines are accessing the widgets by their
> public and stable API.
>

Well, if you assume that if widget A parent's is a Container, and that
container is inside, say, a ComboBox, to figure out if "A" is an entry
or a button inside of combobox. If for any reason you need to put
another container between the combobox instance, and the other
widgets, you basically can't because you will break all engines. There
are dozens of other examples for this.

I consider those details opaque to any consumer of a public API, which
includes the API provided for engine writters.

At the same time, this kind of crawling makes engine writting and
maintaining really hard, since you need to browse gtk+'s internals to
do the right thing.


> It would also be possible to introduce aliases for the sake of
> theming, e.g. "GtkTreeViewColumnHeader" for a GtkButton inside a
> treeview. Maybe such an approach would be feasible to bridge the gaps
> between the "widget access" and the "no widget access" camps?

That's exactly the kind of thing that we want to propose. That's why
we need something richer and more flexible than the detail string. If
a column header button is rendered, the engine should not by any means
crawl the structure to figure it out. The api call should have that
information out of the box.

>
> - Rob
>



-- 
Cheers,
Alberto Ruiz