Re: Continue flame about WEIRD gtk2 design.

[Martyn Russell <ginxd btopenworld com>]

I have to say I 100% agree with what you said Archit, but I would add 
that I do think that GLIBs implementation of GList's (i.e. doubly linked 
lists) could be better.  Where I work we have implemented a similar 
library to GLIB and the list includes a next, previous, head and foot 
pointer for each item in the list.  When an item is removed, the list 
pointer doesnt change, however in GList changes (i.e. append and 
remove...etc) it returns a pointer to a GList which implies the Glist is 
reallocated.  If this is the case, it would be a lot easier and better 
if instead, the item was removed and the previous and next items in the 
list point to each other in their own 'next' and 'previous' pointers. 
This also makes it safer when accessing the list from different places 
in the code in an asynchronous orientated application.

Regards,

Martyn

Archit Baweja wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> Maxim Koshelev <max krascoal ru> writes:
>
>  
>
> > Hello there again,
> > I've pointed out before that new tree/list model/view sructures has the same
> > disadvantages which was in gtk+1.2.x. To be accurate I need to notice that
> > some of disadvantages was fixed (e.g. ability to store pointer to the
> > row) but
> > some of them pass through the versions to GTK+-2.x.
> > I try to confirm my words by examples:
> >
> > 1) There is no any gtk_tree_model_iter_prev() routine for fast access
> > to previous
> >    
>
> I see a gtk_list_store_insert_after() and gtk_list_store_insert_before().
> Thats what ur looking for.
>
>  
>
> > iterator because gtk-team does not know about double linked lists and
> > prefer to use
> > single linked lists.
> >    
>
> I you see the header files of gtktreestore.h and gtkliststore.h (the two
> GtkTreeModel implementations), you'll see that they indeed are using GList 
> and *not* GSList.
>
>  
>
> > 2) GtkTreeSelection is absolutely unusual structure (at least in
> > <=2.0.6). Again image the
> > list with 100'000 rows with MULTIPLE selection enabled. Simple task to
> > determine
> > "has your list any selection or not" can be solved only in one VERY
> > NONOPTIMAL way.
> > Look through whole list to determine has its rows IS_SELECTED flag or
> > not... (GtkCList
> > is slightly better in this case because it has normal list of selected
> > rows).
> >
> > 3) GtkTreePath is UNUSUAL STRUCTURE FOR OUR INCONVENIENCE!!!
> > I absolutely does not understand WHY WE CANNOT USE ONLY GtkTreeIter
> > for all operations with model/store!!!
> >    
>
> I don't know the exact details on this, but I think there is a GtkTreePath
> in addition to a GtkTreeIter because of the GtkTreeStore implementation of
> the GtkTreeModel interface. GtkTreePath is usefule for multi-level GtkTreeModel
> implementations, like the GtkTreeStore, while GtkTreeIter is only useful for a
> single level. I'm not really sure of this one, but I think thats what it is
> for.
>
>  
>
> > 4) Why gtk-team always tries to hide normal structures inside *.c
> > files?! Are they thinking
> > that another programmers prefer to use expressions like this:
> > ((gtk_supername_of_structure_getting_some_sub_structure_from_another_sub_structure(a,b))->another_sub_routine(c,d))->blablabla
> > (of course I can expand this expression to
> > tmp1=gtk_supername_of...;tmp2=tmp1->another_...)
> >    
>
> Because there is no "private:" (a la OOPs languages) in C. Data hiding.
>
> Hope that helps.
> Archit Baweja
>
> P.S. RTFM! :-)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>
>
> iD8DBQE9eYIY2rWNPKmGjMcRAiw3AJ0cazh1f2nY6gfj6QBJnSy63+z+KQCggPMf
> IxhBmmBGpEK41NkhNo5wahc=
> =KqWX
> -----END PGP SIGNATURE-----
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>