RE: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

["Damon Chaplin" <DAChaplin email msn com>]

> to solve this issue, i'd like to see all child widgets that
> have been created by Gtk internally to be flagged with a new
> widget flag GTK_WIDGET_COMPOSITE_CHILD.
> so if i create a new FS dialog, the FS itself should not
> be flagged, but FS->button_area should. if i then add a
> new widget (e.g. button) to FS->button_area, this widget
> should also not be flagged as a composite child.
> to achive this for widgets that are created internally, and
> to ease the burden on the Gtk/widget programmer, i propose
> the addtion (and actuall application) of two functions (and
> the additional GTK_WIDGET_COMPOSITE_CHILD flag):
>
> void         gtk_widget_push_composite (void);
> void         gtk_widget_pop_composite  (void);

I think this would help solve the problem for simple
composites - Dialog, FileSel, ColorSel, InputDialog, FontSel.

But how do you identify the composite children in the interface
description file (i.e. the XML in Glade) and when setting
properties when the widgets are loaded?

Glade currently uses an extra property, 'child_name', in a widget's
data hash, which holds a string identifying the composite child,
e.g, 'Dialog:ok_button', and then when loading the XML it calls a
gb_widget_get_child() function to get the widget corresponding to
this ID so it can set its properties. It's not very pretty, but it
works. To use this in GTK we would need:

  /* This sets a name to identify a composite child widget */
  void       gtk_widget_set_composite_child_name (GtkWidget *widget,
                                                  gchar     *name);

  /* This gets the composite child widget ID, to be saved to XML. */
  gchar*     gtk_widget_get_composite_child_name (GtkWidget *widget);

  /* This will be overriden in composite widgets to return the child
     widget corresponding to the given ID. */
  GtkWidget* gtk_widget_get_composite_child      (gchar     *name);

If these are used, then the push/pop_composite() functions are not
needed (since you can just check if
gtk_widget_get_composite_child_name() is not NULL).


There is still the problem of complex composites -
GtkNotebook, GtkCList, GtkCTree.
These have extra widgets - notebook tabs & popup menuitems, clist
column title widgets. And the number of extra widgets is not fixed.

(Glade currently uses the child_name again here, but all
tab_labels/clist titles have the same ID - 'Notebook:tab' 'CList:title'
The order of the widgets in the XML file determines the order in the
notebook/clist. But note that gtk_widget_get_composite_child() won't work,
since several children have the same ID.)

I think for GTK we should make sure that all containers work in a more
generic manner, e.g. to add page 2 of a notebook you should be able to
do:
  gtk_container_add_with_args	(GTK_CONTAINER (notebook),
					 notebook_page,
					 "child_type", GTK_NOTEBOOK_PAGE,
					 "page", 2);

 to add the tab for this page you would do:

  gtk_container_add_with_args	(GTK_CONTAINER (notebook),
					 tab_label,
					 "child_type", GTK_NOTEBOOK_TAB,
					 "page", 2);

It may be the case that some Child Args are only applicable to certain types
of children, but I don't think that is a major problem.
It would also be nice to be able to move widgets around without destroying
any
widgets underneath them, just as you can already do in a table. Otherwise if
you change the 'child_type' above you may lose widgets accidentally.


There's also the slight problem that foreach() in GtkNotebook only iterates
over the pages at present, so its difficult for a GUI builder to find the
tab labels/popup menuitems in a generic way. (In Glade I had to add special
code to iterate over the notebook tabs as well.)

Damon