GNOME Bugzilla – Bug 171991
The number of selected rows is incorrect in "cursor-changed" callback.
Last modified: 2006-12-09 17:16:21 UTC
Please describe the problem: The number of selected rows in a GtkTreeVew is incorrect in "cursor-changed" callback when rows are selected with a modefier - Ctrl or Shift. Steps to reproduce: 1. Create a small program reporting the following number in the "cursor-changed" callbacK: gtk_tree_selection_count_selected_rows(gtk_tree_view_get_selection(treeview)) 2. In the TreeView window select rows holding Shift or Control modifier 3. Compare number of selected rows you see with the number of rows reported. Actual results: There's mismatch between shown and reported number of selected rows Expected results: I would like them to be the same. Does this happen every time? Yes. Other information: I have a small program showing the problem and a patch fixing it. I've check the latest CVS today and the bug is still there.
Created attachment 39387 [details] [review] Patch made against gtk+2.0-2.6.3 release OK, attached is the patch which does make the problem go away. Here's the justification for the change: According to what I saw in the code functions gtk_tree_view_real_toggle_cursor_row(tree_view) and gtk_tree_view_real_select_cursor_row(tree_view, FALSE) /* note the FALSE for start_editing */ do approximately the same thing as gtk_tree_view_real_set_cursor(tree_view, path, TRUE, TRUE) does. The only problem with using this last one was a condition (!tree_view->priv->ctrl_pressed) preventing _gtk_tree_selection_internal_select_node() to be called. Taking this into account I've updated GDK_BUTTON_PRESS event handling to call gtk_tree_view_real_set_cursor(tree_view, path, TRUE, TRUE) even when modifiers present and removed !tree_view->priv->ctrl_pressed from the condition in this call. The side effect of this change is that other invocations of this function with the third argument equal TRUE also call _gtk_tree_selection_internal_select_node() even with Ctrl held. To give them their original behavior I've changed this third TRUE in these calls to (!tree_view->priv->ctrl_pressed). The end result is that handling of GDK_BUTTON_PRESS event got fixed and all other calls behave as they did previously. I do hope it helps, Igor
As you can see from the patch I'm a total liar - the patch was made against 2.6.2 and not against 2.6.3 release. :) Igor
Created attachment 39389 [details] Code reproducing the problem Just for completion of the bug report here's the program which can be used to check that problem really exists.
The number of rows is actually correct in the cursor-changed callback. The "problem" is that the cursor-changed signal is emitted before we modify the selection (which will emit the GtkTreeSelection::changed signal). I don't think we should modify this, since it might break applications depending on this behaviour.
Agreed. One of the two has to go first, either the selection changes and the cursor is wrong, or the cursor changes and the selection is wrong. I'd prefer not to change this.
The problem is that behavier is different when modifiers are involved. If you select a row without a modifier you have the right number of selected row - 1 even if before selection there was no row selected. That means that selection without a modifier is done before cursor-changed callback is called. On the other hand, as Kristian pointed out, if Control or Shift are held the selection is updated only after cursor-changed callback is executed. From my point of view it looks a little bit inconsistent. I wonder what application would take into account this difference and work differently depending on how selection is made. Igor
Would you like me to file a document bug report? It will state that when selection is made without modifiers the "cursor-changed" signal is emitted after GtkTreeSelection object corresponding to the GtkTreeView object is updated and before that update if Control or Shift modifiers are used. And that for consistent value of selected rows one need to use "changed" signal of the GtrTreeSelection object directly. Thanks, Igor
Hi, I think Igor is correct that the implementation should be documented if the behavior of values returned in callbacks might differ or can't be trusted when Control or Shift is used. Should this bug be reopened to reflect that documentation is needed? Cheers, (Xref: this is Debian bug http://bugs.debian.org/301610)
So how to get count of selected rows if it doesn't work as expected - by design ?
(In reply to comment #7) > Would you like me to file a document bug report? > > It will state that when selection is made without modifiers the "cursor-changed" > signal is emitted after GtkTreeSelection object corresponding to the GtkTreeView > object is updated and before that update if Control or Shift modifiers are used. > And that for consistent value of selected rows one need to use "changed" signal > of the GtrTreeSelection object directly. I don't think this update to the documentation is necessary. The "cursor-changed" signal has nothing to do with the selection, it notifies you that the position of the cursor has changed -- this does not directly mean that the selection has changed. If you want to monitior changes to the selection you should always use GtkTreeSelection::changed. (In reply to comment #9) > So how to get count of selected rows if it doesn't work as expected - by design > ? gtk_tree_selection_count_selected_rows() works as designed and advertised.