deleting images should move them to Trash

[GoogleCodeExporter]

First of all, if you have any Haxies, InputManagers, SIMBL plugins or
similar operating system hacks installed, please remove them first, restart
the program, and make sure the bug is reproducible without them.

What steps will reproduce the problem?
1. Open an image
2. Press Cmd-Delete
3. Confirm deletion

What is the expected output? What do you see instead?
I expect the image file to be moved to the Trash. Instead, it seems to be 
deleted in-place, with no sign of the image file any more. No way to recover it.

What version of the product are you using? On what operating system?
Version 2.2 on Lion 10.7.0.

Please provide any additional information below.

Original issue reported on code.google.com by t...@thedigitalorchard.ca on 1 Aug 2011 at 7:32

[GoogleCodeExporter]

There are different keys for moving to the trash and deleting permanently. Use 
the other one.

Original comment by paracel...@gmail.com on 1 Aug 2011 at 7:48

• Changed state: Invalid

[GoogleCodeExporter]

Maybe you can enlighten me as to where this other command is, and what it might 
be. :-) I appreciate your quick response, but it didn't help solve my problem. 
I've checked though all of the menu commands (and used the Help menu) and don't 
see a "Move to Trash" command anywhere in the application. There is a "Move 
File" command, which is a little bizarre anyway, but how would one use this to 
move the file to the Trash?

Original comment by t...@thedigitalorchard.ca on 1 Aug 2011 at 7:54

[GoogleCodeExporter]

Furthermore, you position Xee as a replacement of Preview, so I think the 
behavior should be the same between the two. It would make sense for Cmd-Delete 
to move to Trash and some other key combination (Cmd-Shift-Delete) to delete 
permanently. That would be a safer design from a user standpoint and more 
consistent with how other applications may do it.

Original comment by t...@thedigitalorchard.ca on 1 Aug 2011 at 7:56

[GoogleCodeExporter]

Xee is not really a replacement for Preview. It is a image directory browser 
first and foremost, and as such needs to be designed differently.

Also, I misremembered, there are different keys for deleting and deleting after 
confirming. Both will move the file to the trash if it is possible to do so (it 
is not possible on remote volumes, for instance), otherwise they should warn 
that file will be deleted permanently. This matches OS X behavior.

Are you sure you are getting behaviour different from this?

Original comment by paracel...@gmail.com on 1 Aug 2011 at 8:16

[GoogleCodeExporter]

At first I thought you were right that my issue may have been related to remote 
volumes. But I just tried with a local file. Pressing Cmd-Delete presented a 
confirmation dialog telling me that the file will be deleted immediately. I 
confirmed and it was deleted, but nothing appeared in the Trash folder. I still 
don't' see any way of moving a file to the Trash. No other key combination 
triggers a delete operation for me.

Original comment by t...@thedigitalorchard.ca on 1 Aug 2011 at 8:20

[GoogleCodeExporter]

If you drag the same folder to the trash, what happens?

Original comment by paracel...@gmail.com on 1 Aug 2011 at 8:28

[GoogleCodeExporter]

From within Finder? It correctly places the folder in the trash. (It's a local 
folder on a local volume, not remote). I don't see any way to drag the folder 
to the Trash from within Xee.

Also - dragging the current image's proxy icon (from the titlebar) to the Trash 
also does nothing. This should move the file to the Trash. I was about to say 
that this is the same behavior of other applications, but I just tested Preview 
and dragging the proxy icon to the Trash does nothing there either, so maybe 
this is a system-wide bug introduced in Lion? Hmm.

Original comment by t...@thedigitalorchard.ca on 1 Aug 2011 at 8:38

[GoogleCodeExporter]

Very strange. Is there anything unusual at all about that volume?

Original comment by paracel...@gmail.com on 1 Aug 2011 at 8:50

[GoogleCodeExporter]

Nothing strange. Stock hard drive in a MacBook Pro 2.2Ghz (Late 2007). Not 
split into partitions. HFS+ with Journaling.

This may turn out to be a Lion issue. Are you running Lion yet?

Original comment by t...@thedigitalorchard.ca on 1 Aug 2011 at 8:52

[GoogleCodeExporter]

Yes, it works as expected here.

What Xee does is check two flags for volumes, "IsOnInternalBus" and 
"IsOnExternalBus". If neither is true, it triggers the delete-in-place mode. 
Those two should cover internal drives and drives on USB and Firewire 
respectively, so it is pretty strange if an internal drive has neither one set.

Since I can't reproduce it, fixing it will be hard. It might be an OS X bug, 
but it's hard to tell without being able to do some testing.

Opening this up in case anyone else has any more information to post about it.

Original comment by paracel...@gmail.com on 1 Aug 2011 at 9:13

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Low

[GoogleCodeExporter]

Issue 278 has been merged into this issue.

Original comment by paracel...@gmail.com on 30 Dec 2011 at 1:29

[GoogleCodeExporter]

Using newer APIs in Xee 3 probably fixes this.

Original comment by paracel...@gmail.com on 5 Feb 2013 at 11:23

• Changed state: Fixed