On Mon, Oct 13, 2008 at 4:58 PM, Alberto Ruiz <[EMAIL PROTECTED]> wrote:
[...] >> 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. There are two different cases of parent-matching to consider. One is for composite widget where, agreed, it may not be desireable to depend on implementation details. QT introduces the notion of "sub-controls" [1] for that, a thing we are also discussing for the CSS engine. The other case is "legitimate" parent/position matching, for example to theme buttons inside a button box (see [2] for a mockup) or even/odd row colouring in a treeview. It would be on the one hand prone to limit designers' possibilities by restricting that second variant in any way, and on the other hand hard to provide a complete representation of a window's widget hierarchy. Here iteration through parent widgets is needed. [1] http://doc.trolltech.com/4.5/stylesheet-syntax.html#sub-controls [2] http://www.gnome.org/~robsta/gtk-css-engine/screenshots/child-index-selector.png - Rob _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
