Re: Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)

[Tim Janik <timj imendio com>]

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