If you just happen to have something highlighted when hitting the empty trash kbd shortcut, whatever was highlighted will be unceremoniously thrown in the trash!
Yikes!
It takes another application of the shortcut to actually delete what was just accidentally put in the trash, but this could cause a very nasty surprise.
I use the kbd shortcut all the time without thinking too much about what’s in the trash because I know what I’ve put in there.
Please change this behaviour to only do the empty-the-trash task.
BTW, I really appreciate the inbox & trash concept in DTP. Heck I appreciate everything about it.
Using the three pane window, if I highlight a document and hit command-delete or even just the delete key by itself, that document is sent to the Trash.
If I highlight a document and hit command-shift-delete (DEVONthink Pro>Empty Trash), I get a warning that the Trash will be permanently deleted and, upon clicking OK, it is deleted, but the highlighted document remains untouched.
This works as I would expect – or am I missing something from your description?
Yes. Try emptying the trash with a document (or a whole directory!) highlighted, but with nothing in the trash before you issue the empty trash command.
There are points in this important discussion where it would help to explicitly specific “DTP Trash” or “OS X Trash” since emptying DTP Trash usually moves documents to OS X Trash. Thanks.
Using the Shift-Command-Delete shortcut to empty DTP Trash when it’s empty and items are selected moves the selected items to DTP Trash. When DTP Trash is empty its shortcut correctly displays as inactive in the main DTP menu:
Seems the problem is the Shift-Command modifiers are being ignored in this context, causing an unmodified Delete to move selected items to DTP Trash instead of ignoring the disabled shortcut.
This bug would be more serious if it could cause items to be unintentionally sent directly to OS X Trash (bypassing DTP Trash) though there doesn’t seem to be a way to do it.
Okay… that’s not as major as I thought. I still don’t like it though. Perhaps if the menu item was always valid (even if it didn’t have a real result)…
DTP’s Shift-Command-Delete Empty Trash shortcut should only be active when its Trash is non-empty. In 2.0pb1 it’s misbehaving like an unmodified Delete when Trash is empty.
Yes, I was only speaking of the DT Trash. And I’d call the situation pretty major. Not unrecoverable IF you’re paying attention, but if an entire directory got in the trash, then you nonchalantly go about your work and an hour later you empty the trash, then poof that entire directory is gone. You might not even know about it until the next day or week!
It’s probably fairly trivial to fix, some kind of trap for the extra key but it does need attention.
Though after emptying DTP Trash you still have to empty OS X Trash before it’s completely gone.
Actually, I dislike the implementation of DTP Trash but this is an example of how the OS X Trash layer can be a useful safety net.
Briefly, I’d prefer an “IMAP style” deletion, with items being marked as deleted and remaining in their original locations instead of being explicitly moved to a Trash group. Selecting Trash would still display deleted items (essentially an “Item is Deleted” Smart Group), but undeleting would simply remove the deleted status with original locations preserved. Emptying DTP Trash could still move items to OS X Trash, although I’d rather it be optional than mandatory.
No doubt such an obvious and risky bug will be fixed.
The reason I brought up the menu validation is that it is (AFAIK) the easiest and most bug-free way to trap the “Empty Trash” shortcut and defuse it before OS X pursues the risky behavior (“move to Trash”). No custom code involved to keep the “Empty Trash” shortcut valid even if there are no items in the Trash, and in fact it might even simplify the code a bit.
I don’t see the logic of having an Empty Trash command/shortcut enabled when it would be non-operational. That contradicts my expectations anyway. Or maybe you mean something else but don’t waste your time trying to explain it to me.
Reminds me of a more general discussion a few months ago about leaving command/shortcuts enabled (and/or visible in menus) in contexts they won’t work.
Sure, it’s not good, but it’s better IMHO than adding code or leaving this unremedied for a period of time. It has no ill effects that I know of other than possibly irritating people who right-click the trash can or click the App menu and expect to see the option grayed out. IMHO that’s far preferable to adding custom code (and therefore bugs, most likely) dealing with file deletion and trash emptying
Regardless of expectations, when OS X Trash is empty Finder’s Finder (app) menu always looks like this (on most Leopard systems):
And referring to the earlier screenshot you’ll see the same disabled Empty Trash… command (minus the trailing ellipsis, which could arguably be there) and shortcut under DTP’s DEVONthink Pro (app) menu when its Trash is empty. The menu is correct in both cases/contexts; it’s only DTP’s shortcut that’s misbehaving when items are selected.
If I hadn’t mentioned the menu it could have remained irrelevant to what really needs attention and is likely relatively easy to fix: the incorrect and undesirable shortcut action. Silly me for unintentionally complicating the issue.
