Re: [gtk-list] Bugs in GtkCList/GtkCTree

[Lars Hamann <lars gtk org>]

On Sun, Feb 07, 1999 at 04:14:09PM -0600, Andrew P. Lentvorski wrote:

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

[...]
Mmmh, I agree, automatic selection in EXTENDED_SELECTION can be
annoying in that case. I'm willing to change that, if nobody objects.

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

Yes. Thanks for your hint. ;)

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

Well, it's not a bug, it's a feature. CList does not select/unselect any
rows until it receives a button_release_event. So after the second drag
selection row 6-9 are still selected and only row 1-5 are added to the
selection.

bye,
  Lars