RE: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

[Tim Janik <timj gtk org>]

On Mon, 24 Aug 1998, Damon Chaplin wrote:

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

you should have a special tag in there, identifying those widgets
as composites. then you need to treat them specially, i.e. if you
got descriptions for a composite_child widget, you don't create
it on your own, but apply the values to it, once you've craeted
its parent and notice that it exists.

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

as i stated earlier, i think that is too much of a hurdle, for being
implemented consistently. i'd rather like to have a generic mechanism
implemented that attempts to give composite widgets a generic name,
i.e. consisting of the widgets type, plus it's position within the
parents child lists upon creation (can be queried through the child
arg::position(widget->parent, widget)).

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

yep, and these can even be supplied by the user, in which case they are
not composite children. still, i think the above mentioned method would
apply.

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

the "child_type" you refer to could actually be implemented automatically 
by the notebook itself, but i don't see its advantages. you still have the
problem of identifying the widgets (e.g. the different tab labels) and
culd merely get away with tagging those widgets with a builder specific tag.

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

hm, i'm not sure what you mean here, in principle you should be able to move
any widget around by saving its current child args, reparenting it and
then reapply the child args (once the container type remains).
if you mean moving widgets around within the parents children list, that
should be taken care of by the ::position child arg, which just needs to be
implemented consistently.

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

yep, that needs to be solved as well. assuming we got something like the
composite_child flag, we are finally able to include all of these widgets into
the foreach calls as well, which would also "heal" some existing problems with
sensitivity and style propagation. functions like e.g. gtk_widget_show_all()
would then skip those widgets that are flagged as composite_child.

> 
> Damon
> 
> 

---
ciaoTJ