Re: BUG: gtk_list_store_remove() causes GtkTreeView cursor to disappear

[Jonathan Blandford <jrb redhat com>]

"Brian J. Murrell" <gtk-list-in interlinx bc ca> writes:

> This is more or less the same issue I raised with the GtkCList widget.
> A little different though.
> 
> When I move the cursor on a GtkTreeView to an item and then delete it
> (with say a button, like in the editable-cells gtk demo), the cursor
> (the highligted bar) disappears.  I have to either click on the list
> (if I even have a mouse!) to get a new one or move the cursor down
> with an arrow key, at which point I am at the top of the list again.

This isn't really a bug.  You (the programmer) should place the cursor
in the next interesting spot (and possibly select the row).  I really
did not want to do this, as I feel it violates the "least surprise"
principle.  You should really handle selecting the next row yourself in
a well written app.

In the example you gave, instead of listening to the row_delete signal,
can't you catch the event which triggers the row deletion, and figure
out from there where you want to move it.

> But this doesn't exactly work.  It gives me the following errors on
> stderr:

That possibly sounds like a real bug.  If you can get a small test case
and file it at bugzilla.gnome.org, I'll look at it.

Thanks,
-Jonathan