On Fri, Jul 19, 2002 at 05:34:46PM -0400, Jonathan Blandford wrote: > > 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. OK, fair enough. Peace on this issue. As you say below, it's not really a huge amount of code for the programmer to handle it, if the interface(s) are there to query the list about the position of the cursor and whether it's at the top of the list, the bottom or somewhere between. It's this last part that seems to be missing. Or more likely, I am just not seeing it. > 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. Right. Flexibility is good. But in the (what must be a very common) case of simply wanting the cursor to stay pretty much where it was (either before or after the row deleted) the given interfaces do not seem to make it relatively easy. > 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. Awesome! Can you point me to an example to learn by? > I suppose I could add something like: > > gtk_tree_view_enable_magic_cursor() > > but I'm not really wild about that. Fair enough. And I will stop on the "built-in" solution, if I can code up the application specific one easily enough. > > > 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. But you meant something different. I must have misunderstood. If the gtk_list_store_remove() is what causes the row to be removed (from the list and from the user's view) and GtkListStore's row-deleted signal to be raised where else would I put the code to handle to the cursor move other than those two places? I must be missing something about how the View, Model and Store work together. b. -- Brian J. Murrell
Attachment:
pgpciMXURgdzL.pgp
Description: PGP signature