On Fri, 26 Sep 2008, Peter Clifton wrote:
On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote:
As i said above, there is no need at all for micro speed optimization
in these code paths. And using GTK_IS_HBOX() adds a type registration
dependency, which prevents things like moving GtkHBox/GtkVBox into a
different lib like libgtk3compat.
Forget the micro-optimization on the string lookups. My real point was
this:
If you're leaving all the behavioual defaults for the old widgets in Gtk
3.0, then going to pains to detect "compat" replacement widgets with the
old class names to change behaviour, then you might as well have just
left the compat widgets in the library.
For real cleanup, the widgets would have to be removed (including any
special-casing of behavioural defaults). If that means the base-class of
any compat widgets needs to support changing the defaults during
inheritance, that looks to me like how it should be done.
Right, but per-instance fields still aren't neccessary for this kind of
special casing. Adding a single method needs_compat_defaults() that
HBox/VBox would override to return TRUE is good enough to figure the
specialized class bahviour (and allows moving HBox/VBox out of Gtk+ still).
g_type_is_named() would just have been a lazy shorthand for this ;)
Peter Clifton
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
