276883 - Allow downloaded files to be dragged and dropped from the download manager

Status: RESOLVED FIXED

(Camino Graveyard :: Downloading, enhancement, P4)

Description

[Bruce Davidson]

(This text is from the third part of bug 230320, which I'm spinning off into
this separate bug to keep the different issues separate).

A way to *drag* a file from the download manager (once it's downloaded, of
course) so I could either drag it to some folder or drag it to some application
in the Dock (for example). Opening isn't always what I want. (Original reporter
Paul Guyot, cc'ed on this bug).

Comment 1

[Bruce Davidson]

Moving this to the future milestone, that bug 230320 was targetted for; its not
likely to happen any time soon unless someone steps up to the plate to implement it.

Comment 2

[Mike Pinkerton (not reading bugmail)]

we did talk about this, the problem is that it disrupts the selection method of
the row in the table. If the interaction can be done correctly, I'd be all for
it as I think it's a good idea. 

Comment 3

[Chris Lawson (gone)]

Targeting at 1.2 with the rest of our DL manager bugs. We need to look at this stuff pretty soon.

Comment 4

[Ben Fowler]

I am quite sure that I would never use this. 

The operations mentioned are the province of the finder, and our 
re-implementing these functions are going to founder on the question of 
whether a drag means copy or move (at the very least)

"Dragging to some folder" => Use 'Reveal in Finder' and then the Finder to do
file-related operations.

"Open with..." => Use 'Reveal in Finder' and then the Finder to do
file-related operations.

I would support giving the icon in the Download window the same rights and
responsibilities as a Proxy icon.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 7

[Stuart Morgan]

Attachment: fix

This bug hit my "annoyed me too many times in a short period" threshold, so taking. The patch turns the icon for a completed download that is still locatable into a drag source.

Comment 8

[froodian (Ian Leue)]

Comment on attachment 285622 [details] [diff] [review]
fix

Looking at the code I'm not sure why, but double-click on the icon itself always drags instead of opens (even though you're checking for that first).

Also not sure why looking at the code, but these drags seem to always be copies (ie you can't actually move the file this way)

Comment 9

[Stuart Morgan]

Attachment: v2

Fixes the click issue, which unfortunately means implementing all the drag and pasteboard logic. Finder just doesn't seem to believe in moves though, no matter what flag combos I tried, but this will at least allow drag-to-open and the like.

Comment 10

[Stuart Morgan]

Attachment: v3

Now with correct member variable naming.

Comment 11

[froodian (Ian Leue)]

Moves work fine for me if I have |draggingSourceOperationMaskForLocal| return

(NSDragOperationMove | NSDragOperationCopy | NSDragOperationGeneric | NSDragOperationLink | NSDragOperationDelete);

This opens up a can of worms about what to do with the progress view item though, since we'll have lost track of the actual file after we move it.  Perhaps just remove it like you're doing w/ deletes already?

Also, drags won't work if the click starts when Camino is in the background.  Not sure.  Not sure why codewise...

Comment 12

[Stuart Morgan]

Attachment: v4

Handles moving. I don't think dragging from the background is something we really care about.

Comment 13

[froodian (Ian Leue)]

Comment on attachment 286429 [details] [diff] [review]
v4

>   ProgressViewController* mProgressController;     // WEAK reference
>+  NSEvent* mFileIconMouseDownEvent;                // strong ref

nit: make these two ref-type comments match in style

>+- (void)dealloc {

nit: method-scope { on new line

Since we test the drag against whether a file with that name exists, not whether the manager knows about the file, we can get a weird situation where we'll drag files that have been lost-track-of, but which still exist (or when files of the same name as a deleted file exist).

Also, the doesn't-work-from-background thing is kinda a problem, since it holds true even if Camino is frontmost, but the downloads window isn't.  Also, behavior OS-wide is for drags to work regardless of whether their window is frontmost.  Maybe it just needs a mouseDown call to be passed down from ProgressDlgController under certain situations?

Comment 14

[Stuart Morgan]

Attachment: v5

Trying one more time; comments addressed. This time there's a nib as well, since constantly looking up the icon view by tag seemed silly.

Comment 15

[Stuart Morgan]

Attachment: nib

Comment 16

[froodian (Ian Leue)]

Comment on attachment 286484 [details] [diff] [review]
v5

Looks great.  r=me

Comment 17

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 286484 [details] [diff] [review]
v5

sr=pink

Comment 18

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH.