2008/10/13 Robert Staudinger <[EMAIL PROTECTED]>: > 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.
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. -- Un saludo, Alberto Ruiz _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
