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

[Peter Clifton <pcjc2 cam ac uk>]

On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote:
> On Fri, 26 Sep 2008, Peter Clifton wrote:
> 
> > On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:
> 
> >> - Change additional defaults as needed, e.g.:
> >>    gtk_box_init (GtkBox *self)
> >>    {
> >>      gboolean compat_type =
> >>        g_type_is_named (G_OBJECT_TYPE (box), "GtkHBox") ||
> >>        g_type_is_named (G_OBJECT_TYPE (box), "GtkVBox");
> >>      if (!compat_type)
> >>        gtk_widget_show (self); // GtkBox defaults to ::visible=TRUE
> >>    }
> >
> > Why not store the defaults as class struct memebers. GtkBox can
> > initialise the class members to the new defaults, then the shallow
> > compat subclasses can override them.
> 
> Because it adds complexity and memory overhead without any neccessity.

Ok fair enough on the complexity front. (Since I recall that GTK won't
allow any struct members to be accessible anymore?)

This is the class struct I'm talking about here. That is
number_of_defaults integers / boolean values, instantiated in memory 1 +
as many GtkBox subclasses exist times.

[snip]

> > It also avoids leaving any trace of the names GtkHBox / GtkVBox in GTK.
> > It seems kindof silly remove the TINY API for using these old classes,
> > but have to retain lots of:
> >
> > if (detect_old_class_names) {
> >  foo;
> > else
> >  bar;
> >
> > Since the legacy is still there! Plus the code would presumably run much
> > faster if you could just do GTK_IS_HBOX() rather than look up the name
> > by string.
> 
> 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.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)