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 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.

> This avoids the string compare for each operation where multiple
> defaults exist. (I assume from the  is necessary with the type lookup).

There is no need to avoid a string lookup here, widget packing is hardly
time critical (i.e. it totally pales compared to e.g. the time spent on
realizing, size requesting or size allocating widgets).

> 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.

> Peter Clifton

---
ciaoTJ