Re: [gtk-list] Re: referring to children of a container

[Havoc Pennington <rhpennin midway uchicago edu>]

I'll try to give some concrete suggestions...

On Fri, 25 Sep 1998, Tim Janik wrote:
> 
> GtkNotebook introduces gtk_notebook_page_num() and gtk_notebook_reorder_child()

My gtk_notebook_current_child() patch would fix the last "impossible"
thing to do on GtkNotebook. Or: 
GtkWidget* gtk_notebook_find_child(gint index).

> GtkBox introduces gtk_box_reorder_child(), gtk_box_query_child_packing() and
>        gtk_box_set_child_packing()

I don't think reorder_child is useful in most cases, because a box is not
an index-oriented thing (esp. if you pack both start and end).

For example, I have a dynamic box representing a series of data columns to
import from a file. I would like each data column widget in the box to
have an "add after" and a "remove" button. "remove" is easy of course;
"add after" I don't know how to do. Given a pointer to a data column
widget, what index is the position after it? No way to find out, as far as
I can tell.

So one possible addition (this would be nice for GtkMenu too) is:

gtk_box_pack_after(GtkBox* box, GtkWidget* child, GtkWidget* new_child,
                   gboolean expand, gboolean fill, guint padding);

and the equivalent pack_before. 

Alternatively:
gint gtk_box_index(GtkWidget* child);

Or even:
gint gtk_container_index(GtkWidget* child);

> GtkTable at least exports the attach options through the object argument
>          interface, we should eventually provide a gtk_table_reattach()
>          function to aquire the same functionality through the normal
>          API, but it would essentially just do a gtk_container_remove()
>          and then invoke gtk_table_attach() again.

My dynamic table does reattach this way; it calls remove() then attach(). 
I'm just worried that it isn't especially efficient to do this, if, say,
you have 10 columns of widgets and you want to insert one at the
beginning.

Internally, GtkTable could implement insert_row and insert_column by
resizing itself and then memcpying all the children, which would be nicer. 
Failing that, a freeze() - thaw() pair a la clist would make it nicer.

Also as I said earlier a dynamic table would generally have to be
homogeneous, and then you could also have a cell-based API and avoid
having to specify four attachment corners.

> GtkList lets you query a child's poition with gtk_list_child_position()
>         but currently lacks a _reorder implementation.
> GtkPacker implements gtk_packer_reorder_child() and gtk_packer_configure()
> GtkFixed implements gtk_fixed_move()

I haven't really used these widgets, so I don't know. However GtkFixed,
GtkLayout, and GnomeCanvas all implement move() taking a GtkWidget*
instead of an index, and that's pretty nice IMO.

> i agree that the API names seem kinda randomly picked, and it would
> actually be a good idea to change it in some places so we get more
> consistent function names. but then again, the differences in the APIs
> for dynamic changes to container children originate in the different
> functionality that the containers provide (e.g. a GtkTable doesn't associate
> a certain index with a child).
> 

Which is good. I think the indexes are evil unless you are actually using
an array rather than a list and getting efficiency. Most code seems to
have bad hacks to go from pointer to index; the index is only convenient
if e.g. you know what menu items you have and count them and then you
don't have to pass a pointer around in the code. The prime example is
gnome-app-helper, where the menu is a static array and you can count
entries to see what your index is. 

For code where the widgets represent data of some kind rather than "pure"
UI components, you need a unique runtime-determined handle on each child
because you have to add/remove/alter the child as the data changes. So
then the index API's are kind of annoying.

Since it's a tradeoff I guess it would be nice to have both as often as
possible.

Havoc