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

[Jared Krinke <furiousj u washington edu>]

I know I can't speak for Joseph, but I think he might have been getting
at the point that removing rows from a GtkListStore seems like one
operation and shouldn't require using many different data types whose
concepts overlap.

I completely understand that the API is complex because all the power
that comes with it (e.g. the ability to manipulate GtkTreeStores with
the same API) can come in handy quite often. But for a GtkListStore, I
don't feel that things like iterators should be required. Iterators are,
as you said, for iterating, they shouldn't be required to simply remove
one row from a GtkListStore (especially when you don't care about it
being set to the next row).

Adding such API on to GTK would probably make the people that unified
the list and tree code mad, but I feel that trees and lists have
fundamental differences that should not be forgotten.

Either way, now that at least there's some material on how to tie all
the API together, I don't think this is a terrible issue, just a minor
annoyance. And I'll admit that most of my problems were related to the
fact that I'm fairly new to GTK, but I'm guessing most documentation is
written for newbies.

On Wed, 2003-07-30 at 07:33, martyn 2 russell bt com wrote:
> > 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
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list