After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 363643 - Shift+arrow expands selection, Shift+mouse doesn't
Shift+arrow expands selection, Shift+mouse doesn't
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.14.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 405715 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-10-20 12:16 UTC by Michael Chudobiak
Modified: 2010-06-29 07:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Michael Chudobiak 2006-10-20 12:16:43 UTC
If you select a file and delete it, the selection moves to the next file.

Then if you then press shift+rightarrow, the selection expands (two files selected), as expected.

However, if you delete a file and then shift+mouseclick, the selection does not expand. It moves the selection to the single file that was clicked.

Shouldn't both operations have the same effect?

This may be a Gtk bug/feature. Please re-classify if appropriate. It was originally reported as a gthumb bug (for its browser view) - see bug 315176.

- Mike
Comment 1 Nelson Benitez 2006-10-20 12:53:15 UTC
Does this occur to list view or icon view ?
Comment 2 Michael Chudobiak 2006-10-20 12:56:13 UTC
This only occurs in icon view. It works correctly in list view.

- Mike
Comment 3 Michael Chudobiak 2006-10-20 12:59:17 UTC
The post-delete selection mode is slightly different between list and icon views as well. In list view, the new selection background is solid blue. In icon view, the new selection is just marked with a dotted line around filename. Maybe that's a clue?
Comment 4 Michael Chudobiak 2006-10-20 13:24:29 UTC
Also: gthumb shows the same difference of behaviour between the icon and list modes. That is, both post-delete selection-expansion methods work in list mode, but shift+mouseclick does not work in slide (=icon) mode.

So something is odd in the shared libraries...


- Mike
Comment 5 Stephane Chauveau 2006-10-20 16:19:02 UTC
The problem is likely to be caused by the fact that shift+mouseclick does not really care about the current selection. It only considers the last item that was physically clicked.

For example, try the following scenario: 

 (1) 5 images A B C D and E in that order
 (2) click on A 
 (3) control-click on C
     -> A and C should be selected 
 (4) control-click on C again
     -> A is the only one selected
 (5) shift-click on E  

The final result is that C, D and E are selected.

That does not make sense if shift-click is supposed to extend the selection but that makes sense if shift-click select the range from the last clicked item (in that case C even though it was not selected) to E. 

So there must be somewhere a variable that points to the last clicked item.
This is the one that should be updated when a new item is automatically selected after a delete or move. 

 


Comment 6 Nelson Benitez 2006-10-22 16:39:54 UTC
Just some clarify about comment 3, when a file is deleted the "normal" behaviour is what you see in icon view, i.e. not selecting any icon just givin it focus(the dotted line around) so if you press down arrow key the next icon is selected. In list view when you delete a file the next file is selected (instead of just giving it focus), this change was made when fixing bug 122618 . 

Maybe we could check if now gtktreeview has got the ability to give focus to a row and so revert the patch in bug 122618  and make a real fix so the icon view and list view have same behaviour.
Comment 7 Michael Chudobiak 2006-10-23 13:25:26 UTC
Nelson,

For rapid processing of image files it would be nicer if the icon view worked like the list view, so that after a delete the next file gets selected (not just the focus).

In other words, I'd prefer it if the patch in bug 122618 wasn't reverted - instead, modify it to work in icon mode too.

- Mike
Comment 8 Michael Chudobiak 2007-02-08 13:15:36 UTC
*** Bug 405715 has been marked as a duplicate of this bug. ***
Comment 9 Paolo Bacchilega 2007-02-08 21:24:29 UTC
this should be fixed in trunk now
Comment 10 Marcus Carlson 2010-06-28 22:18:19 UTC
If fixed, could we mark the bug as fixed as well?
Comment 11 Paolo Bacchilega 2010-06-29 07:40:32 UTC
yes.