Re: Continue flame about WEIRD gtk2 design.

[Tristan Van Berkom <vantr touchtunes com>]

GList operations return the lists "head node" incase
it would change

example:

GList *list = NULL;

list = g_list_append(list, data)

in this case your list head is no longer null.
also if you use g_list_prepend you "head node"
will change every time. 

If the code looks a little complicated 
(ie allocaters etc...) I think
it's because (I could be wrong here) glib uses an
inteface to memory allocation in order to allocate
logical "chunks" of memory and minimize memory
fragmentation. (but I didn't read that part of
the code)

        -Tristan



Martyn Russell wrote:
> 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
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list