RE: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

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

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

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


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


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

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

Damon