Re: Some introspection on GtkContainer children.

[Damon Chaplin <damon karuna uklinux net>]

I've had a look at all the composite children that Glade uses for GTK+
widgets. I think all of these could have been avoided if the widgets had
been written slightly differently:

  GladeChildOKButton;
  GladeChildCancelButton;
  GladeChildApplyButton;
  GladeChildHelpButton;
  GladeChildSaveButton;
  GladeChildCloseButton;

These are the buttons used on many of the dialogs in GTK+. As I said
before, if the dialogs had a "response" signal, these would be
unnecessary.


  GladeChildMenuItemImage;  (the image in a GtkImageMenuItem)
  GladeChildComboEntry;     (the GtkEntry inside the old GtkCombo)
  GladeChildComboList;      (the GtkList inside the old GtkCombo)
  GladeChildFontSelection;  (inside the font selection dialog)
  GladeChildColorSelection; (inside the color selection dialog)

These could be avoided if the parent widget provided the necessary
properties itself, and just passed the values on to the children.
(Similar to how many of the GtkFileChooser-related properties work.)


  GladeChildDialogVBox;     (used for GtkDialog and GtkFileChooser)
  GladeChildDialogActionArea; (ditto)

For GtkDialog we could have just got rid of these completely, and used
regular child widgets for everything (with helpers to set up standard
dialogs for you). Buttons would have "response_id" properties, and when
clicked the button would find its toplevel dialog/window widget and emit
a "response" signal on it.

Another option is for these widgets to act like a standard container, so
you can pack widgets into them.


So basically if widgets are designed with GUI builders in mind, I think
you can avoid composite children issues 99% of the time.

Damon