File Browser Deletes Unselected Files #34467

New Issue

Harley Acheson · 2013-02-28T03:08:27+01:00

Harley Acheson commented

2013-02-28 03:08:27 +01:00

%%%--- Operating System, Graphics card ---

Windows 7 64-bit. 32-bit Blender build
ATI Radeon HD 5570

- Blender version with error

Blender 2.66 Revision 54822

- Short description of error ---

File Browser editor deletes file under mouse, not selected files

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

I put 9 text files in a test folder.
In Text Editor, Text / Open Text Block
Browse to test folder that contains the text files
Select the first text file
Shift-click to select a few more files (but not all)

While these files are selected, move your mouse pointer over a file that is not selected
Press "delete" key and you will get the "OK? Delete" operator confirmation
Confirm and see that the file deleted was the one under the mouse pointer, not the ones that were selected.
%%%

%%%--- Operating System, Graphics card --- Windows 7 64-bit. 32-bit Blender build ATI Radeon HD 5570 - Blender version with error Blender 2.66 Revision 54822 - Short description of error --- File Browser editor deletes file under mouse, not selected files - Steps for others to reproduce the error (preferably based on attached .blend file) --- I put 9 text files in a test folder. In Text Editor, Text / Open Text Block Browse to test folder that contains the text files Select the first text file Shift-click to select a few more files (but not all) While these files are selected, move your mouse pointer over a file that is not selected Press "delete" key and you will get the "OK? Delete" operator confirmation Confirm and see that the file deleted was the one under the mouse pointer, not the ones that were selected. %%%

Harley Acheson commented

2013-02-28 03:08:27 +01:00

Changed status to: 'Open'

Philipp Oeser commented

2013-02-28 14:07:49 +01:00

%%%I can confirm this.

the op deletes the active (highlited) file. Not the selected. I agree this being a little unintuitive. But this goes way back to 2.49 (and I guess much further). I am not sure if this should be changed?

At least the operator description is misleading ("Delete selected file"). It should read "Delete active file" imo.

I have attached a patch that renames the operator description and also brings back the message we had in 2.49 [which tells you which file will actually be deleted].

If there is interest in changing the behaviour to not delete the active but all selected files instead I will be glad to look into this as well

Greetz
Philipp

%%%

%%%I can confirm this. the op deletes the _active_ (highlited) file. Not the selected. I agree this being a little unintuitive. But this goes way back to 2.49 (and I guess much further). I am not sure if this should be changed? At least the operator description is misleading ("Delete selected file"). It should read "Delete active file" imo. I have attached a patch that renames the operator description and also brings back the message we had in 2.49 [which tells you which file will actually be deleted]. If there is interest in changing the behaviour to _not_ delete the active but all selected files instead I will be glad to look into this as well Greetz Philipp %%%

Harley Acheson commented

2013-02-28 15:50:58 +01:00

%%%But I would argue that it is not deleting the "active" file either. If this were to follow our usual use of active/selected then deleting "selected" would delete all I have selected, while deleting "active" would delete the last selected item. In this case we seem to doing a pre-selection highlight and then working on that instead of what the user has actually selected.

%%%

%%%But I would argue that it is not deleting the "active" file either. If this were to follow our usual use of active/selected then deleting "selected" would delete all I have selected, while deleting "active" would delete the last selected item. In this case we seem to doing a pre-selection highlight and then working on that *instead* of what the user has actually selected. %%%

Harley Acheson commented

2013-02-28 17:15:29 +01:00

%%%My take on fixing this...

If the usual behavior is desired then I would keep it, but only when nothing is selected. So if NOTHING is selected then pressing the "delete" key should target the file under the mouse, but give an operator confirmation that names the file.

However, if anything is actually selected then use that list instead. The operator confirmation should say something like "Delete the selected file(s)" and all the selected files should be deleted.

I have attached an image, "FileManagerDelete.png" that shows what the current behavior looks like.%%%

%%%My take on fixing this... If the usual behavior is desired then I would keep it, but only when nothing is selected. So if *NOTHING* is selected then pressing the "delete" key should target the file under the mouse, but give an operator confirmation that names the file. However, if anything is actually selected then use that list instead. The operator confirmation should say something like "Delete the selected file(s)" and all the selected files should be deleted. I have attached an image, "FileManagerDelete.png" that shows what the current behavior looks like.%%%

Andrea Weikert commented

2013-02-28 18:30:14 +01:00

%%%I'll be taking a look. I agree that the current behaviour is a bit confusing - I will probably go with changing the operator to act on the selected files, I think that would be the expected user behaviour.
Expect commit in the next days...
%%%

%%%I'll be taking a look. I agree that the current behaviour is a bit confusing - I will probably go with changing the operator to act on the selected files, I think that would be the expected user behaviour. Expect commit in the next days... %%%

Harley Acheson commented

2013-02-28 22:04:11 +01:00

%%%Thanks Andrea,

A user noticed (and I confirmed) that these deletions don't go to the Windows Recycle Bin or to the Mac Trash, so they are not so easily recovered.

It would be nice to have per-OS file deletion routines in Ghost. So calling SHFileOperationW for Windows, FSMoveObjectToTrashSync for Mac, and moving to ~/.Trash on Linux.

Cheers, Harley
%%%

%%%Thanks Andrea, A user noticed (and I confirmed) that these deletions don't go to the Windows Recycle Bin or to the Mac Trash, so they are not so easily recovered. It would be nice to have per-OS file deletion routines in Ghost. So calling SHFileOperationW for Windows, FSMoveObjectToTrashSync for Mac, and moving to ~/.Trash on Linux. Cheers, Harley %%%

Campbell Barton commented

2013-03-03 14:28:02 +01:00

%%%Note, it would be worth considering to remove this functionality, Gnome/GTK on linux dont have the ability to manipulate files and I found it works quite nice.

Basically file selectors in GTK are non destructive (with the exception of directory creation) so you cant have any accidents,
I would prefer this - then allowing to delete file selections which could backfire.%%%

%%%Note, it would be worth considering to remove this functionality, Gnome/GTK on linux dont have the ability to manipulate files and I found it works quite nice. Basically file selectors in GTK are non destructive (with the exception of directory creation) so you cant have any accidents, I would prefer this - then allowing to delete file selections which could backfire.%%%

Harley Acheson commented

2013-03-03 17:13:44 +01:00

%%%Personally, I have never deleted a file from within the File Browser editor. I just found the functionality by accident and then saw the strange selection behavior. So for me it could be removed without me really noticing...

But to remove it because it is easy to delete files by accident seems like a weak reason. Although it is easy to do this one destructive thing (deleting) it is just as easy to do something equally as destructive: overwriting an existing file, and I don't think anyone would remove that functionality. In fact, I would even argue that deletions within the app, where you can view file contents, is safer that forcing the user to do so outside the app where that is not possible.

And if we were to follow my previous comment above (using Windows Recycle Bin, Mac Trash, and Linux ~/,Trash) then this deletion operation would actually be much less destructive than overwriting existing files. With that in place I would even add a "delete" button to the UI.%%%

%%%Personally, I have never deleted a file from within the File Browser editor. I just found the functionality by accident and then saw the strange selection behavior. So for me it could be removed without me really noticing... But to remove it because it is easy to delete files by accident seems like a weak reason. Although it is easy to do this one destructive thing (deleting) it is just as easy to do something equally as destructive: overwriting an existing file, and I don't think anyone would remove that functionality. In fact, I would even argue that deletions within the app, where you can view file contents, is safer that forcing the user to do so outside the app where that is not possible. And if we were to follow my previous comment above (using Windows Recycle Bin, Mac Trash, and Linux ~/,Trash) then this deletion operation would actually be much less destructive than overwriting existing files. With that in place I would even add a "delete" button to the UI.%%%

Campbell Barton commented

2013-03-04 05:32:58 +01:00

%%%@Harley, better supporting OS delete as you suggest is fine to add in the sense if we support this feature we may as well support it properly.

Just prefer to stop our file selector from becoming a file manager, even through historically - this has been the case.

You could even move files between dirtectories in 2.4x using it as a split-screen file manager :)

On Linux most apps I use can't delete files in their file selector and I have to say I don't really miss it from the days I used windows where it was possible.%%%

%%%@Harley, better supporting OS delete as you suggest is fine to add in the sense if we support this feature we may as well support it properly. Just prefer to stop our file selector from becoming a file manager, even through historically - this has been the case. - You could even move files between dirtectories in 2.4x using it as a split-screen file manager :) On Linux most apps I use can't delete files in their file selector and I have to say I don't really miss it from the days I used windows where it was possible.%%%

Harley Acheson commented

2013-03-04 05:58:24 +01:00

%%%It is just so hard to remove features once they are in. Although I've never used it, and you don't really like it, I'm sure there are still enough people that do that there would be large hue and cry and gnashing of teeth if it were removed.%%%

Andrea Weikert commented

2013-03-24 22:32:39 +01:00

%%%Fixed in revision 55556. The file delete operator now acts on selected files.
Closing issue.
(I will try to incorporate some of the suggested changes about the Trash bin once we have a better structure in the area of handling OS dependencies)%%%

%%%Fixed in revision 55556. The file delete operator now acts on selected files. Closing issue. (I will try to incorporate some of the suggested changes about the Trash bin once we have a better structure in the area of handling OS dependencies)%%%

Andrea Weikert commented

2013-03-24 22:33:13 +01:00

Changed status from 'Open' to: 'Resolved'

Andrea Weikert closed this issue

2013-03-24 22:33:13 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

File Browser Deletes Unselected Files #34467