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

On Thu, 25 Sep 2008, Mike Kestner wrote:

The types would essentially be
boilerplate, so it's not like they are going to be a maintenance issue.

If the motivation for removing the types is that, "things aren't as
beautiful as they could be" then that argument doesn't really outweigh
the pain of porting existing code.  Especially when the cost of
supporting existing code is so low.

There doesn't really need to be any pain involved for the application
developers at all here. We've previously talked about libgtk3compat
(or libgtk3graveyard) and this looks like another good example for
having it. I.e. the box changes can look as follows:

- Make GtkBox a constructable widget (effectively introducing a new
  user level widget as Mitch described)

- Add orientation switching to GtkBox:
    gtk_box_set_orientation (GtkBox*, GtkOrientation);
  This effectively moves all hbox_size_request, vbox_size_request,
  hbox_size_allocate and vbox_size_allocate logic into gtkbox.c

- Make GtkHBox and GtkVBox very shallow compatibility types derived
  from GtkBox. This involves one G_DEFINE_TYPE() macro and implementing
  gtk_hbox_new and gtk_vbox_new as simple wrappers around g_object_new.
  (They'd effectively call gtk_box_set_orientation() in their _init

- Change the packing defaults for gtk_box_pack_start_defaults and friends
  unless old compat types are detected, i.e.:
    gtk_box_pack_start_defaults (GtkBox *box, GtkWidget *child)
      gboolean compat_type =
        g_type_is_named (G_OBJECT_TYPE (box), "GtkHBox") ||
        g_type_is_named (G_OBJECT_TYPE (box), "GtkVBox");
      gboolean expand = compat_type ? TRUE : FALSE;
      gboolean fill = compat_type ? TRUE : FALSE;
      gtk_box_pack_start (box, child, expand, fill, 0);
  I've used a new helper function g_type_is_named() here, since adding
  that might be helpful in a couple other compat cases as well. It roughly
  amounts to g_type_is_a (type, g_type_from_name (type_name)); and doesn't
  require the checked for type to actually be registered.

- 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

- The shallow compat types GtkHBox and GtkVBox could be moved into a
  libgtk3compat that allows fine grained "undeprecation", e.g.:
    #define GTK_DISABLE_DEPRECATED 1 // allow code cleanups
    #define GTK_COMPAT_HBOX        1 // still need GtkHBox though
  So as long as GTK_COMPAT_{H|V}BOX are defined, *no* existing
  application code will need changing.

- Locking the orientation for GtkHBox and GtkVBox widgets could be added
  in addition, but I don't think it's strictly neccessary. After all,
  GtkHBox and GtkVBox will continue as mere wrappers to help people in
  their porting efforts and IMHO should be kept as simple as possible.
  The officially supported box interface will be GtkBox anyway.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]