RE: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

[Tim Janik <timj gtk org>]

On Tue, 25 Aug 1998, Damon Chaplin wrote:

> 
> > 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)).
> 
> OK. So composite children are uniquely identified by the position arg.
> Is it possible that the position could change as new widgets are added?
> If that is true then we need to be careful when loading widgets, to make
> sure we access the right one. I think that is OK.

yep, we need to make a decision though when that composite name is
created. e.g. if we automatically assign a composite name to widgets
upon their addtion to a container, we might end up with multiple
widgets having the same name, e.g.
gtk_widget_push_composite ();
prepend (hbox, label_new ("1"));
prepend (hbox, label_new ("2"));
gtk_widget_pop_composite ();
now label "1" will have the same composite name as label "2", e.g.
"GtkLabel_1".
it might be better to add a sequential counter to containers which hold
composite children, so the above two labels in question would be named
"GtkLabel_1" "GtkLabel_2" depending on the order they got added to the
container, regardless of append/prepend.
the other possibility is to assign a composite name to a widget at the
moment where an API call requests it, i.e.

gtk_widget_get_composite_name (GtkWidget *widget)
{
  gchar *composite_name;
  
  if (!GTK_WIDGET_COMPOSITE_CHILD (widget))
    return NULL;
  
  composite_name = gtk_object_get_data (GTK_OBJECT (widget), "gtk-composite-name");
  if (!composite_name)
  {
    create a composite name for widget, building it up from its type name
    and the child arg ::position.
  }
  return composite_name;
}

i'm not yet sure what would be the best solution for this, though the latter
has the advantage, that containers which are aware of the composite child
naming problem could set it explicitely. maybe the possibility for explicit
setting in combination with a sequential id would be the best way.

> How will the position arg work with notebooks? Say there are 4 pages.
> Will the page widgets be at positions 0-3, the tabs 4-7, and the popup
> menu items 8-11? (or something like that. I'm assuming it's a gint)
> Would it be read-only for some containers (e.g. notebooks) and read-write
> for others (e.g. box)?

the::position argument is currently supported (read-write of course) for
GtkBox, GtkPacker and GtkNotebook. more containers are to follow, all of which
*have* to implement this as read-write arguments.

> > > 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);
> 
> > 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.
> 
> But when you load a notebook tab widget, you have to have some way of
> telling the notebook that it is a tab, rather than a page or a menu item,
> don't you? Currently if you just add it, it assumes it is a new page.

ahh, ok i finally get what you are aiming at ;)
with the child_type argument you are proposing we would be able to
use the generic gtk_container_add () to add tab or menu labels...
this is a definite possibility, currently the notebook features
three child arguments for pages: GtkNotebook::position, 
GtkNotebook::tab_label and GtkNotebook::menu_label, where the latter
two are of type GTK_TYPE_STRING. i'm still not sure whether this is the right
approach, since they could just as well be of type GTK_TYPE_WIDGET.
i basically modeled these argument after GtkButton::label, which also
takes a string as argument.
if we made those GTK_TYPE_WIDGET, a gui builder could offer the user to
supply a certain page with associated widgets, that could be build up
independantly (e.g. a hbox, holding a pixmap and a label).

> > > 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.
> 
> I was trying to think in general terms of how a user would add widgets
> to complicated containers like a notebook. For tables, boxes etc. its
> easy - the user can drag a widget from the palette onto the table and
> use the child args in the property editor to move it around. If a
> widget is moved temporarily over another in a table, the hidden widget
> is not destroyed, just invisible, so you don't have to worry about
> accidentally losing widgets.
> 
> So how would a user add widgets to something like a notebook tab?

hm, what about implementing the above mentioned change, and then
offering the user to drop widgets into the property editor, onto
the tab_label or menu_label arguments? (we could also, instead of
modifying those types from string to widget, offer widget type arguments,
named GtkNotebook::tab_widget and GtkNotebook::menu_widget, that way the
user is still able to simply specify strings if so desired, or provide
real widgets for more advanced layouts. this would also be more consistent
with the GtkButton behaviour, where you can either use GtkButton::label or
GtkContainer::child. btw, the automatic labels need to be flagged as
composite children of course).

> I thought that the user would drag a widget from the palette onto the
> notebook, and it would be added in a default position, i.e. a new page.
> The user could then use the child args in the property editor to change
> it to a tab, and also set its page number. Before the page number is
> set correctly, the widget may also occupy the same space as another widget,
> which led to my remark above about not deleting widgets which are
> obsured. (Currently a notebook page or tab can only hold one widget,
> so the obscured widget would have to be destroyed.)

yep, that's certainly right for tab and menu labels, but at least not
for pages, if you got page 1 and 2 already and then add another page at
position 2, it'll get inserted so the old page 2 becomes page 3.

> 
> Damon
> 

---
ciaoTJ