RE: gtk-app-devel-list digest, Vol 1 #1567 - 14 msgs

[martyn 2 russell bt com]

> I agree, the GTKTreeView is insanely complex.  I can't understand why
> there are multiple different ways of representing a row, and each one
only
> supports some functionality.  You end up writing the bulk of your code
> just manipulating row selections, going through several conversions to
get
> one row representation to translate to another one, with no direct
> conversion available.  And what the heck is "iter" supposed to mean
> anyway?  I have seen at least this many:

Iter means iterator and it is meant for *iterating* the list.

> 
> path string

String representation of Path? Need I say more? What happens if you know
if is at 1:3:2, how would you do it without this?

> path

This points to a particular place in the tree, not a row. If for
example, you are ONLY interested in the 5th item, the path will point to
that regardless of data changes on in the store.

> iter

For traversing the tree/list item by item.

> row reference

I have not yet needed to use this.  It looks to me (from the
documentation) that it is used as a reference for the programmer to a
row, and it follows the path through all the changes that occur, so that
when you do gtk_tree_row_reference_get_path () it will still point to
the same node (unless it has been deleted) even if the path changes.

> index

This is obvious.

> 
> Are there a few more I've missed?  This really needs to be chopped
down to
> size.
> 

No. Personally I prefer to have more than ONE way to do something, it
offers a choice to the developer.

> The docs certainly don't help much.  The layers and layers of
abstraction
> for even the most basic of data types (e.g. int) are mind boggling,
and
> the docs on say, g_objects and g_values are mostly blank.  

I agree with this, it is irritating that g_object and g_value (i.e. the
foundation for GTK) is not documented.

> I hope this
> isn't a permanent condition.  I've looked at the Window$ API, and it
> shocked me compared to say, Posix or TCL/TK.  GTK looks about as
complex,
> due to the innumerable layers of abstraction.

I disagree that GTK looks as complex as Windows, plus you do get used to
the GtkTreeView API and it does not seem as difficult as it appears at
first after a while.
 
> Subject: Removing/Reordering Multiple Selections in GtkTreeModel
> From: Jared Krinke <furiousj@u.washington.edu>
> To: GtkAppDevelList <gtk-app-devel-list@gnome.org>
> Date: 30 Jul 2003 00:51:29 -0700
> 
> I just recently had quite a bit of trouble figuring out how to remove
> all of the selected rows from a gtk_list_store. As near as I can tell,
> there is no simple way to do this and using
> gtk_tree_selection_get_selected_rows() is necessary.
> 
> I think this is a pretty messy API for when working with
GtkListStores.
> ...

How should it be improved? If you think it should be improved write to
the gtk-devel-list@gnome.org and tell them how you would make it
simpler.

Regards,
Martyn