GNOME Bugzilla – Bug 100973
get_cursor does not report TreeViewColumn correctly.
Last modified: 2011-02-04 16:11:56 UTC
This is for v. 2.0.9. I may misunderstand the API here, but when when I use get_cursor() from a cursor-changed callback, I only get the right TreeViewColumn when I'm clicking on a different row. When clicking on different columns in the same row, the TreeViewColumn doesn't change. Here's my callback: static void cursor_changed (GtkTreeView *view, gpointer data) { GtkTreePath *path; GtkTreeViewColumn *viewcol; int i; gint *indices; gtk_tree_view_get_cursor(view, &path, &viewcol); i = 0; while (viewcol!=NULL && viewcol!=gtk_tree_view_get_column(view, i)) i++; indices = gtk_tree_path_get_indices(path); g_print("(%d, %d)\n", indices[0], i); gtk_tree_path_free(path); }
This is still the case with gtk+ 2.2.0. I'm upgrading the severity to major.
Created attachment 13465 [details] [review] Adds a cursor_changed callback and a "Report Cursor" button to the editable_cells demo.
I'm upping the priority on this one. Not being able to determine what column the cursor is in is somewhat debilitating for some applications. I hope this is not too presumptious or against protocol. Attached above is a a simple patch to the gtk+-2.2.0 dist that adds some tests for this to the editable_cells.c demo in the demo/gtk-demo directory.
Seems to happen because the focus column is changed after setting the cursor (those two changes happen indenpent from eachother). So this is either (a) NOTABUG (b) or we also need to emit cursor-changed after setting the focus-column. jrb?
So there's no way to take action based on the cell the user is editing? I want to pop up a menu of items for that column on a key press event.
I think the cleanest approach in this case is writing your own cell renderer.
Sigh. I was afraid you'd say that ;} Well, if this is NOTABUG, I'll try opening an RFE. Writing a custom CellRendererText in C would probably not be too hard, but doing it in python looks like it would be pretty challenging, if it's even possible.
Looking back at Kristian's original explanation, I'm not sure it's clear that this problem is not related to cursor-changed. I modified my test to call get_cursor on a key press so that there was no chance of a focus change. get_cursor will not report the cursor correctly if the last focused cell was in the same row (you get the old cursor position). Do I misunderstand what cursor means in this context? I thought it referred to the text cursor (the one that blinks.)
Managed to come up with a hack that does what I need: gboolean tree_view_get_editing_cell(GtkTreeView *view, GtkTreePath **path, GtkTreeViewColumn **column) { GtkAllocation alloc; GtkWidget *toplevel; GtkWidget *focus_widget; gint cell_x, cell_y; toplevel = gtk_widget_get_toplevel(GTK_WIDGET(view)); focus_widget = gtk_window_get_focus(GTK_WINDOW(toplevel)); if (!(GTK_IS_ENTRY(focus_widget))) return FALSE; alloc = focus_widget->allocation; gtk_tree_view_get_path_at_pos(view, alloc.x, alloc.y, path, column, &cell_x, &cell_y); if (path && column) return TRUE; return FALSE; }
Fixed on HEAD/stable.