GNOME Bugzilla – Bug 509432
Incorrect "X selected items" count in status bar
Last modified: 2008-04-26 22:43:09 UTC
Please describe the problem: After doing some selections/deselections, the status bar does not tell the truth about how many files/folders are currently selected Steps to reproduce: 1. Open a folder containing several files or subfolders, and view it as icons. 2. Click on any file to select it - choose a file which is not shown on the far left of the window. The status bar now shows information about the single selected item. 3. Hold SHIFT, and press LEFT to add the item shown to left of the selected item. Two files will be selected, and the status bar will change to reflect this. 4. Hold SHIFT again, and press RIGHT to deselect the file that was just added to the selection, so that only one item is selected. Now, the status bar is NOT updated, and still says two items are selected. Actual results: (See reproduction) Expected results: (Obvious) Does this happen every time? Yes, tested on two different computers, both running Ubuntu. Other information:
Forgot to explain: It can be reproduced in MANY ways, basically selecting any number (2+) of files using any method and then deselecting all but one using only the keyboard and holding the SHIFT-key. In fact, if selecting a couple of random files using the mouse and then playing around with the SHIFT+direction keys reveal more strange behaviours (which files are selected/deselected become very unpredictable).
This happens also in 2.21.5 but not in list mode. Confirming.
Could be related to bug 512894
Created attachment 109853 [details] [review] 509432-always-use-rubberband-select.patch - always use rubberband_select() method for selecting - drop select_one_unselect_others() which seemed redundant and did not cause selection_changed signal to be emitted - removed g_assert on icon->was_selected_before_rubberband - I discussed that with awalton on IRC and he agreed that it was unnecessary to check it for a bit - I'm not sure about atk notification - I put it there because it's also emitted from select_one_unselect_others() and select_range() but feel free to correct me on that one
We talked yesterday on IRC about my patch above and you suggested to keep it simple, possibly one-liner. However, I'm not sure if that's really possible because of how keyboard_move_to() is currently implemented. Specifically, there's a call to select_one_unselect_others() which selects one icon but doesn't emit selection_changed (even when selection has changed). Now, even when we remove "container->details->keyboard_rubberband_start != icon" from if() and rubberband_select() is called when we move focus "back" to where we started, selection_changed isn't emitted because rubberband_select() doesn't change anything - because select_one_unselect_others() already did. I hope this makes sense to you. I still believe this redundant selection can be safely removed, the only thing I'm not sure about is atk notification.
Whatever may be the proper approach coding-wise I've just successfully tested the patch and I could not spot any side-effects.
Paweł: You are right that the select_one_unselect_others() call breaks the selection change notification. You did not mention this in your original comment 4, though, so I thought the change was purely cosmetic. I was not very happy with the ATK call because you placed it outside the functions actually dealing with selection/keynav. I just committed a slightly different patch which moves the focus tracking to the selection/keynav functions - to trunk and to the GNOME 2.22 branch: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14092 http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14093 Closing, thanks for your efforts.