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 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"?
> 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.
So if I decide to deal with GtkTreeIters instead of GtkTreePaths, I
can use gtk_tree_model_iter_next() to advance to the next item, but
there is no gtk_tree_model_iter_prev() to go to the previous item.
As you can see, this is not (as far as I can tell) so simple. I
simply want to be able to say:
if (row_being_deleted == row_cursor_is_on) {
if (cursor_is_on_last_row) {
if (cursor_is_on_first_row) {
clear_cursor(); // no rows in the list
} else {
move_cursor_to_prev_row();
}
} else {
move_cursor_to_next_row();
}
}
This does not seem terribly doable with either GtkTreePaths or
GtkTreeIters.
> 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?
> 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.
Perhaps I can. But it doesn't change the fact that there is no
comprehensive way to make the cursor traverse up and down the
GtkTreeView and know when the cursor is on the first or last item in
the (sorted) list.
b.
--
Brian J. Murrell
Attachment:
pgpThSzo1SCzM.pgp
Description: PGP signature