Re: Continue flame about WEIRD gtk2 design.



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]