Bugs in GtkCList/GtkCTree

["Andrew P. Lentvorski" <andrewl deliverator io com>]

Two bugs, first in CList

Create a CList with some rows and extended selection mode.  Select a
couple of rows.  Now delete all of the selected rows.  The row after the
last deleted row is now selected.  This is a bug.

Why is this a bug?

If you try and delete all the rows in the selection by walking through the
selection list, you eventually remove all the rows in the CList since
the selection never goes to NULL.

BTW, deletion does appear to reset the selection list row numbers
appropriately.  This is a real boon in that I don't have to go back and
sort all the rows I'm deleting and keep track of what it does to the
row numbers.

The only alternative would be to copy out the selection list to a new
list and walk that.  However, you would have to sort the list and then
decrement all the data by one each time you deleted an element earlier
in the list.  Or sort backwards and delete in reverse order.

A gtk_clist_remove_list(CList *,GList *) function would get around
most of this crud as Gtk has access to the internal selection mechanisms.
It could just mark all the rows to be deleted and the crush it all at once.
This would probably be far more efficient than clients writing the code
to squash every individual row with all the attendant cleanup of the selection
and updating.  (hint. hint.)

However, I realize that Gtk is in feature freeze for the moment.  So I would
settle for the selection just going to NULL if you've deleted it all.

Second bug, in CTree (presumably also in CList):

Create a CTree with some rows and extended selection mode.  Click on row
6 and drag to row 9.  Thus, Rows 6,7,8,9 are now selected.  Now, click
on row 1 and drag to row 9.  Thus Rows 1,2,3,4,5,6,7,8,9 are selected.
The selection list, however, returns them in the order 6,7,8,9,1,2,3,4,5
instead of 1,2,3,4,5,6,7,8,9 like they were selected.  Should be pretty
easy to fix as all it really needs is for a click to erase the prior
selection before starting a new one.

Andy L.