GNOME Bugzilla – Bug 144144
Allow undo of lost selection
Last modified: 2021-06-18 15:17:57 UTC
Right-clicking a file/folder not select the it. Doing so means you lose the previous selection, which may have been important to the user. Selecting an item should only happen when you left-click something, not when you right click it. (This seems to have been fixed in 1.x (bug 40881), but it didn't seem appropriate to reopen such an old bug for 2.x)
This isn't quite the same as the old bug. In the old bug, if you had selected several items, and then right-clicked on one of the selected items, the multi-item selection was lost. This was wrong. It should have enabled a context menu for the entire group. In 2.6.x, the behavior just described functions correctly... If you right-click on a non-selected folder, you presumably want to access its context menu, not that of your selection. At this time, the clicked upon item should be selected so that the user can tell what items a context menu operation will act upon.
Right, but perhaps either the previous selection should be restored after the popup is dismissed, or some other mechanism is used to highlight the target of the click.
> Right, but perhaps either the previous selection should be restored after the > popup is dismissed, or some other mechanism is used to highlight the target of > the click. Well isn't the target highlighted just by being selected? I think the current behavior is intuitive and obvious.
The problem that caused me to file this bug was the selection being lost when you right-clicked to bring up the context menu on something else in the same folder (including the folder background). So maybe you just spent a lot of time selecting a bunch of files and you went to create a new folder to put them in by right-clicking on the folder background, or missed clicking on the selection (a lot harder to do now that the transaprent parts of icons are now considered when doing hit-detection), but either way the selection is lost. Yes, the target is highlighted when selected and this is intuitive and obvious, but you're not changing the selection when right-clicking on something (that is what the left hand button is for) and doing so should not cause the thing you right-clicked on to be selected, hence destroying the existing selection.
Interesting... gnome-terminal: Select text, right click somewhere else, keep selection. gedit: Select text, right click somewhere else, keep selection. gaim: Select buddy, right click another buddy, get a new selection. Eveolution: Select mail/folder, right click somewhere else, get a new selection. Nautilus: Select file(s), click somewhere else (othe file or background, doesn't matter), lose the selection (background) or get a new selection (file). OpenOffice Calc: Select cells, right click another cell, lose the selection. OpenOffice Writer: Select text, right click somewhere else, lose the selection. Anyway, reopening, since the question has been answered long ago. Maybe GTK+, rather than a Nautilus issue?
Changing component to "general", version to "unspecified", priority to "low" and severity to "enhancement". It is an interesting fundamental discussion that definitly doesn't belong here. I'm CCing usability list to get some feedback.
Well, historically the standard behaviour on most platforms is that right-click = "select the object under the cursor and show the popup menu for the selection". (I thought the GNOME HIG actually recommended this behaviour too, but I can't find any such guideline right now). Specifically: - if the object is already selected, don't change the current selection - if the object is not already selected, lose the current selection first. Provided we do this consistently, I'd say the issue of losing selection is actually somewhat orthogonal-- right-clicking in the wrong place is just one of several ways you can lose a hard-fought selection, and there's certainly an argument for being able to 'undo' selection changes in nautilus, evolution and elsewhere, just as you can in (say) GIMP. One obvious problem is that major apps like nautilus and evolution still don't support undo after all these years. Even if they did, it's debatable whether selections ought to be included in the regular undo stack-- traditionally, they wouldn't be (except for special cases like the aforementioned GIMP, where selections are more complex beasts), as their high frequency and lack of associated data loss or change in application behaviour means they'd mostly just be 'noise' that you'd have to wade through to undo more significant actions. It's certainly an interesting problem, though, and one that I don't recall seeing any serious attempts to solve... maybe a nice little project for next year's GSoC? :)
(In reply to comment #7) > Well, historically the standard behaviour on most platforms is that right-click > = "select the object under the cursor and show the popup menu for the > selection". (I thought the GNOME HIG actually recommended this behaviour too, > but I can't find any such guideline right now). Specifically: > > - if the object is already selected, don't change the current selection > - if the object is not already selected, lose the current selection first. Hmm, fair enough. What about clicking on a background when there is a selection, however? In the examples above, text selection seems to let you keep the selection when you right-click elsewhere. Maybe because selected text can be a small target, but also perhaps the background isn't a terribly interesting thing to click on. This would let you lasso a bunch of files, right-click the background to create a new folder and then move the files into it. > It's certainly an interesting problem, though, and one that I don't recall > seeing any serious attempts to solve... maybe a nice little project for next > year's GSoC? :) Adding undo or not losing the selection? ;)
For the specific use case you mention, we now have a way to create a new directory from the items in the selection. For the losing the selection behavior, we use the GTK+ default behavior and as Calum mentions this is intentional. I'm going to retitle the bug to add support for using undo for selections. I'm not sure it is a good idea but worth considering.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.