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

[Xavier Bestel <xavier bestel free fr>]

On Mon, 2008-10-13 at 15:58 +0100, Alberto Ruiz wrote:
> 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.

OTOH if you want to specifically theme a complex widget, you have to
know what its parts are. I don't think you can reallistically make a
custom look to a widget if you don't know what's inside.

	Xav