On Fri, Oct 10, 2008 at 6:22 PM, Alberto Ruiz <[EMAIL PROTECTED]> wrote:
[...] > I think that the new API should not allow people to acess to > GtkWidget, this prevents implementation changes since engines end up > depending on Widget implementation details (such as the way containers > are used and where in those containers are the elements placed, I'm > thinking in "TreeView > Label" precedency use case here). I think > GtkStyle should go away and be replaced by something that would > provide this information. The problem with this approach is that if you disallow accessing the widget instance, engines can only ever do things that have been thought of /before/. The CSS engine would not have been possible like that, you really want a "constructionist" API, that allows for tinkering. If the nesting of a composite widget is part of the stable gtk API, why whould the themes not be allowed to just as well rely on it? > Another huge annoyance is the inability to provide information about > siblings, at the moment, the only way to inform about those things is > the detail string, and once is set, you can't change it. We couldn't > use most of the css selector patterns such as "Label + Entry" or > "Notebook.tab:first-tab". Again, the GtkStyle replacement should > provide that context information. GtkStyle is not to blame, it's the containers/widgets that don't export this information. In any case, if you'd like to provide the ability to match against arbitrary widget trees you'd really have to instantiate an abstract representation of the widget nesting from each toplevel down to the non-containers, including all the widgets' style properties. The option of restricting matching depth to some arbitrary number does not sound like a solution. - Rob _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
