MVC in GTK+. TreeModel's issues.

[Эльдар Инсафутдинов]

Hi everybody!
I am newby in gtk application development. I sure like the general idea abut the library. But I faced an issue I want to tell you about.
Everybody's now talking about API breakage prior to 3.0 release. I started using GTK not long ago. Essential part for me is implementing custom TreeModel. I came from Qt camp(because I changed programming language). So in my opinion the way it is done in Qt is much much better. I'll try to explain.
First of all some code examples.
http://www.everfall.com/paste/id.php?4al6rmlvuc1n - this is TreeModel implementation in D programming language, it's a gtkd wrapper of gtk.
http://www.everfall.com/paste/id.php?75ty7zbaqisy - and this is custom TreeModel written using Qt.
First impression is that gtk code is 2 times longer. And this is just a list, without any children, tree structure! I am now working on make it tree-capable - and code is increasing dramatically.
Secondly. In gtk I have to implement a lot of methods of GtkTreeModelIface which are duplicating, I mean they don't bring any new information. http://scentric.net/tutorial/sec-custom-models-what.html - list of necessary methods to implement.
1)
iter_children - tell whether the row represented by a given iter has any children or not
iter_n_children - tell how many children a row represented by a given iter has
The first method is superfluous, because if second method is implemented - it can tell whether the row has children or not by retutning 0 or >=1.
2)
iter_nth_child - set a given iter structure to the n-th child of a given parent iter
iter_next - take an iter structure and make it point to the next row
These two methods also do the same job. We dont need iter_next, because if we can point to the nth row using iter_nth_child method, we can also point to the  (n+1)th row using the same method. In iter_next we need also to take care about if nth item is last - but why? If we have already iter_n_children method which tells how many children a row represented by a given iter has.
3)
get_iter - take a tree path and fill an iter structure so that you know which row it refers to
get_path - take an iter and convert it into a tree path, ie. the 'physical' position within the model 
TreeIter and TreePaths. I dont know why need to have separated classes for one instance? In Qt there is one QModelIndex. That's all. I started implementing GetIter and GetPath methods to convert path to iter and visa versa, and I can say that it is very very complicated in case the tree structure.
So once again - if we look at Qt code closely we can see that we don't have to do a lot of really hard work. I think if break API in GTK 3.0 - serious work on rewriting TreeModels should be one of the most important parts.
Maybe somebody has already been working on this problem, I don't know. But that's what I want to tell.
Thank you, with best wishes Eldar Insafutdinov.

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