Re: [Gnome-bindings] Iterator and access functions

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson writes:
>  > 1) One problem which gtk-- has has quite frequently is is iterator
>  > and access functions.  That is that many of the gtk+ functions take
>  > integer offset into lists.   This means even though we may have a cache
>  > to the data items address we can not use it. 
>  > 
>  > 2) Another common problem is that occasionally gtk+ returns a
>  > pointer to a structure which we of course must copy if we want to
>  > keep.   (I think in general it is best if gtk+ always return a pointer 
>  > to info which must be copied rather than having the user take ownership.)
>  > However, in some places you also must copy it just to pass it back to the 
>  > same widget.
> 
> 
> I think these two problems should be reported to the gtk-devel mailing list,
> rather than the bindings one.
> Of course, it would be easy to change the bindings temporarily to work around
> these problems, however it would definitly be better if there was a proper fi
> x
> in gtk+ itself. Although the first one looks more like an enhancement request
> (I think Havoc has planned to at least partially rewrite clist and ctree for
> gtk+1.4), the second one is definitly a bug report.

Well, the first runs throughout the fundimental design of the kit.  
Many things were structured with ints as the only access resulting in
the behavior described.  (CList, List, Toolbar, MenuShell, Boxes, Button
Box)  They are all lists underlying attempting to be cast as vectors
by gtk+.  Thus you can not place an iterator into those lists and 
have an item added without losing your place.  I have presented the 
problem to the gtk+ developers to no avail.  So basically unless I
can find others who feel it is a similar problem they will do 
nothing.  (Yes, I know menus and others may rarely have 50 itmes,
but still tracing through lists when providing access could be done 
essentially for free make no sense to me.)

I do realize that iterators are really largely a C++ issue.  I
just was interested in seeing if other binders have that same problem.
This problem forces us at times pull large gobs of gtk+ code into
our codebase.

(Note that the iterator problem is very much like the gtk_foo_new
/ gtk_foo_construct  where they simply have functions which do too much.
Row/Column lookups could be done in another function and combined.) 


The second has been reported to the gtk+ bug tracker. 


The related (and totally C++ issue) is that glib/gtk+/gnome
all use GList which is order N for finding the tail.  STL (the
C+ standard) requires O(1) tails and most code uses that.  The result
is horrible performance on anything resembling C++ code because every
line triggers an O(n) through the list sometimes multiple times.  When asked
the gtk+ crew tells us simply cache it if you need it.  However, it is 
impossible to cache something if there is no way to determin if it has been
changed.  If they are telling us to do the impossible and that they 
won't fix it at their level it is equivelent of blowing us off. 
Caches if they exist must be performed by the lowest system which 
does accesses.   One should never assume that some higher system can
cache unless a method for notification of changes is in place. 


--Karl