In Thunar, shift-dragging is no different from normal dragging, while control-dragging inverts the selection. In most file managers I've used, shift-dragging adds to the current selection, while control-dragging subtracts from the selection.
Thanks for reporting ! > In most file managers I've used ... It would help alot if you would put some details here. Which file managers did you use ? What did they do on shift/ctrl-drag ? I tried nautilus, nemo and dolphin: nautilus: shift-drag: invert selection, ctrl-drag: invert selection nemo: shift-drag: invert selection, ctrl-drag: invert selection dolphin: shift-drag: add to selection, ctrl-drag: invert selection thunar: shift-drag: nothing, ctrl-drag: invert selection So far I only can see that ctrl-drag seems to be some kind of standard, inverting the selection. Like thunar does.
@alexxcons I confirm that ctrl+drag always inverts the selection in all file managers I have tried. Windows Explorer has the same Shift+drag behavior as dolphin: - clicking and holding mouse button while Shift is pressed does *not* clear the current selection like thunar does - dragging with shift is pressed adds files to the selection This only affects "icon view" and "compact view", shift+dragging in "detailed view" has a different behavior (you cannot drag selection from a blank area) Changing bug title to reflect that.
I'm fairly certain that shift+drag also adds to the selection for macOS. Since both main commercial OSs have that behavior, and most users are likely familiar with at least one of them, that is what I would expect.
(In reply to Julien [nodiscc] from comment #2) > @alexxcons > > This only affects "icon view" and "compact view", shift+dragging in > "detailed view" has a different behavior (you cannot drag selection from a > blank area) That was new for me .. indeed, in detailed view shift+drag adds to the selection, like proposed. I just checked thunar 1.6.x. Looks like this a regression. In thunar 1.6.x shift+drag as well worked for icon/compact list view. So thanks for raising the issue ! Patches would be very welcome !
Related bug for xfdesktop: #16321
Created attachment 9522 exo-icon-view: Do not cancel selection on shift+drag With this patch Thunar will invert the selection also (same as the other two GTK file managers).
(In reply to Theo Linkspfeifer from comment #6) > Created attachment 9522 > exo-icon-view: Do not cancel selection on shift+drag > > With this patch Thunar will invert the selection also (same as the other two > GTK file managers). Thanks for the patch ! Now I am undecided how best to proceed ... However by applying that patch to exo would mean that we have different hotkeys for icon and detailed view .. not that nice. On the other hand, probably better to do at least something on " shift-drag" instead of doing nothing. We e.g. could push the fix and open a fresh bug about that inconsistency to be fixed later. What would you prefer ?
Created attachment 9534 exo-icon-view: Extend selection on shift+drag I would prefer that Thunar does what the other GTK file managers do though.
(In reply to Theo Linkspfeifer from comment #8) > Created attachment 9534 > exo-icon-view: Extend selection on shift+drag > > I would prefer that Thunar does what the other GTK file managers do though. Thanks again ! If you are still motivated, I as well would be ok to have "invert selection" on both keys, like nemo/nautilus ... though IMO we should than use the same on detailed view. :)
Note that detailed view is a special case. First, select some files via mouse or keyboard. Now, use shift + drag in a single action to select files and unselect(!) them again.
Moving to exo.
Shift+drag in detailed view behaves as shift click, selecting all files in that direction and deselecting all "before" the first selected file. As far as I know, that's expected from listing widgets, if it makes sense to be behave differently I think that should be specific to Thunar and not exo. For all views, in my quick test, Thunar 1.6.x and master have the same behavior, ctrl+drag inverts but also adds to the selection. All in all, I think the requested feature is already covered by ctrl+drag, but I don't mind having a duplicate sans inverting as shift+drag. (In reply to akb825 from comment #3) > I'm fairly certain that shift+drag also adds to the selection for macOS. > Since both main commercial OSs have that behavior, and most users are likely > familiar with at least one of them, that is what I would expect. I understand but disagree with this statement, I used macOS for about one year (2018) and Finder was the worst part of it. Thunar is much more versatile, adding to selection is possible with ctrl+dragging. If it was the other way around, i.e. Finder not having shift+drag, most people would think "Apple probably has a good reason to make this way, I'll just get used to it" (I already observed this pattern many times on Apple users).
(In reply to Andre Miranda from comment #12) > All in all, I think the requested feature is already covered by ctrl+drag, > but I don't mind having a duplicate sans inverting as shift+drag. Thanks alot for looking into it ! So concluded, you and Theo both would go for "invert on shift+drag", that helps alot for making a decision :) That would be this patch, right ? https://bugzilla.xfce.org/attachment.cgi?id=9522 ... just to be sure that I dont push the wrong one :)
> ... just to be sure that I dont push the wrong one :) This patch is needed in any case.
Created attachment 9654 exo-icon-view: Extend selection on shift+drag ... as git-patch, rebased on current master. I'll ask Sean if he wants to review / test before pushing !
The "exo-icon-view:" part in the commit message is not needed or it should be added to the first patch also. I used it to indicate that the patches are for exo while this report was still assigned to Thunar.
Theo Linkspfeifer referenced this bugreport in commit 0b32e3c68f4fb3c4dd845dde1076a22b8f7322bc Extend selection on shift+drag (Bug #7526) https://git.xfce.org/xfce/exo/commit?id=0b32e3c68f4fb3c4dd845dde1076a22b8f7322bc
(In reply to Theo Linkspfeifer from comment #16) > The "exo-icon-view:" part in the commit message is not needed or it should > be added to the first patch also. I used it to indicate that the patches are > for exo while this report was still assigned to Thunar. ok, done. Pushed both patches to exo master, to be released in exo 0.12.12 or exo 0.13.0 Thanks alot for working on this, Theo !