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:

> On Fri, Jul 19, 2002 at 11:59:16AM -0400, Jonathan Blandford wrote:
> > 
> > This isn't really a bug.  You (the programmer) should place the cursor
> > in the next interesting spot (and possibly select the row).
> 
> I agree that I (the programmer :-) should be able to place the cursor
> anywhere, but as an override to a default mechanism.  ISTM that a
> default mechanism of moving the cursor either one after or one before
> the item being deleted is a good default stance that would satisfy 90%
> of the people.  Why make everybody write the same code 9 out of 10
> times?

I'd rather that then leave programmers worrying about whether or not a
particular cursor/selection change was triggered by the user or the
tree.

> > I really
> > did not want to do this, as I feel it violates the "least surprise"
> > principle.
> 
> The cursor disappearing from the widget is "least surprise"?

Yes.  You just deleted the row it was on.

> > You should really handle selecting the next row yourself in
> > a well written app.
> 
> OK, lets go along those lines.  The cursor is dealt with in the
> GtkTreeView in terms of GtkTreePaths.  I can use gtk_tree_path_next()
> and gtk_tree_path_prev() to get the next or previous path
> (respectively).  However I cannot see a way, using GtkTreePaths to
> determine if there is a next GtkTreePath (i.e. if I am on the last row
> of the GtkTreeView).  To do that, I need to deal with GtkTreeModel's
> GtkTreeIters and use gtk_tree_model_iter_next(), which will return
> FALSE if there is no next iter/path/line in the GtkTreeView.  Having
> to deal with a GtkTreeIter just to determine if there is a next row
> seems silly.

That's one solution.  Another solution might be to put the cursor on a
newly created node, or move it to a different location altogether.  The
point is, this is totally context specific.

As for the amount of code, it doesn't seem a huge amount to me.  I do it
all over the place in my code.

I suppose I could add something like:

gtk_tree_view_enable_magic_cursor()

but I'm not really wild about that.

> > 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.
> 
> You mean do the cursor moving where I do the
> 
>   gtk_list_store_remove(GTK_LIST_STORE(model), &iter);
> 
> But then I would be coding the logic to move the cursor everywhere in
> my code that I do the above, whereas catching it in a signal handler
> is a "write-once" solution, no?

You could do that too.  

-Jonathan