GtkCList (was New 'GObject')

[Karl Nelson <kenelson ece ucdavis edu>]

Splitting as requested.

[...]
> > Gtk+ seems to want to install caches and other such kludges to
> > turn the number to item pointer.  But this just plan doesn't work
> > for us.  It would have been just as simple to define the 
> > procedures to use the pointer to the item and then have wrappers
> > that use the index number.  It would give the same interface to
> > the user, but much better to wrapper writer.  You can still 
> > place the caches but I am sure that users can responsibly use
> > a GList* to navigate arround. 
> 
> I guess you are talking about GtkCList. The fact that GtkCList uses a
> GList internally is probably a mistake to begin with.  It probably
> would be better off with an array, or yes, it should provide 
> interfaces that are more iterator friendly.

Having iterator friendly means exposing some of the internals (
or allowing a pointer to the internal be the name of that internal)
and perhaps making them mini objects in their own right.  I like
the way that button is a container and thus can have others.  I
would like it even more if a container and widget were so light
that any list item could be a widget so that each spot on lists
had to be specific.  Then we don't have pixlabel and other
such replication.  You just place a box with a pixmap and text.
(Old procedures hang around for convince if necessary.)

> (I don't think that anybody would defend the fact that the common:
> 
>  row = gtk_clist_append_row(clist, ...)
>  gtk_clist_set_row_data (clist, row, ...)
> )
> 
> is O(n). Actually, note that GtkCTree goes to great lengths to
> duplicate all the functions and provide interface which takes node
> pointers instead of row indices ... so clearly we just have a
> interface mess rather than an intentional design to screw gtk-- over.

I doubt that any interface was intended to "screw gtk-- over".  If
it was I am sure they could make it much harder.  :-)

I am kind of wishing that Gtk+ would bite the bullet and
make a very general Table widget.  It should be dynamic in
all directions and provide iterator interfaces with queues
(head and tail pointers).  Arrays get into the problem of 
reallocation constantly.  You can build quick caches for number
access in both directions.  

This could then be used to replace HBox, VBox, List, CList, etc.
All are just special tabular widgets that could be emulated
with the very general widget.  

This would mean having be able to tell it to remove and keep
a row which give you a new table that you could then readd 
else where.  

Unfortunately, we have wandered off into a horrible Nelson
pipe dream.  I guess we should return to reality.  :-)

--Karl