RE: Continue flame about WEIRD gtk2 design.

["Thomas Cameron" <tom ceisystems com>]

Maxim,

As a new developer in the GTK community, I respect your opinions.
Please excuse any ignorance on my part, as I may not know all of the
"ins" and "outs" of GTK development.

I have recently started a project, using GTK+-2.0.x for the GUI API.  I
have been satisfied thus far with it, versus most of the other GUI APIs
for Linux/Unix environments.  It is simple, intuitive, and nearly
complete.  Almost every feature I have wanted has been in the library!
However, I can see your point about nonoptimal solutions to certain
problems.

My suggestion would be this.  If you are concerned about the way Trees
and Clists are handled, why not create a widget of your own?  You can
even use the source FROM the existing Clist and Tree functions, and
simply improve upon it.  Then, resubmit it to the developers for
inclusion in the project.  This to me would be the best solution to your
problem.  You could make use op doubly-linked lists, more logical
structures, and an optimised "selection" system.  This is especially
true if you need the ability to use LARGE lists of items (100,000 or
more).

Good luck!
Tom Cameron


-----Original Message-----
From: Maxim Koshelev [mailto:max krascoal ru] 
Sent: Wednesday, September 04, 2002 10:31 PM
To: gtk-app-devel-list gnome org
Subject: Continue flame about WEIRD gtk2 design.


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
iterator because gtk-team does not know about double linked lists and 
prefer to use
single linked lists. Just image that your list have about 100'000 rows 
and you want
to move last(selected) row up some times. GTK+2 only allow to programmer

get TreePath
(imbecile structure for our inconvenience) from iter then get previous 
TreePath
then recalc iter from TreePath. For ListStore recalculation routine will

path through whole list...

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!!!

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_...)

What did we (normal programmers which know about the word 
"optimisation") need? We need NORMAL LIST/TREE/ANOTHER_COMPLEX_STRUCTURE
STRUCTURES WITH FAST ACCESS VIA ITERATORS (valid iterators of course) TO

ANY ROW.

Maxim.

_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list