Complete drag 'n drop support by adding drop support

[nomolos]

I'll start working on this one, but I need some clarification. Do you mean drag n' drop support internally, or do you mean with the rest of the OS?

[Sam]

Both. :)

You won't really be able to test native integration on a computer other than Windows or Mac OSX 10.3+ unfortunately. It doesn't work on Linux or earlier versions of OSX.

Java drag 'n drop support is usually handled by the java.awt.dnd package, which should allow components to react to events without knowing or caring if they're internal or external. Swing also supports a 'TransferHandler' object, though LimeWire currently isn't using it. If it makes sense, that may be the way to go, though it also may not be.

Current dnd classes in LimeWire are mostly in the gui/../tables package. The main class that handles setting up drag support is DragManager.

[nomolos]

Alright. Thanks, I'll start getting some work in :)

[nomolos]

I've been playing around with Limewire - just dragging and dropping stuff rather randomly around, and I've been finding that the drag and drop seems fairly complete. I've noticed that dragging from the library window onto the playlist doesn't work, and neither does dragging from a search window into the download box. Is that all that needs to be done?

[Sam]

LimeWire right now can handle dragging -- that is, it'll begin a drag operation and so long as the target is the desktop, it'll work. What it can't handle is dropping. That means that if something is dragged onto LimeWire, it can't support it as a destination.

Ideally it'd be possible to:
- drop a file onto the downloads from the search results and have it start downloading
- drop a file onto the playlist from the library or desktop and have it start playing (or queue up for playing)
- drop a file onto a folder in the library from another folder and move it to that folder
- drop a file onto LimeWire from the desktop and have it become shared.

[nomolos]

Okay, that makes more sense now - the fourth one I would still have questions about, however. What would you want done with the file "on the Desktop" when it's dropped on the library? Should it be moved to a shared folder, copied to a shared folder, or does limewire support things in such a way that only that file could be shared (either permanently or just for the duration of that limewire session). As well, I can think of one more drag n' droppable thing - a piece of text containing a magnet link - but it would be applicable on OS X only.

[Sam]

If a file is dropped onto any arbitrary place in LimeWire, I'd say just share that particular file. If it's dropped on a specific folder in the library, then maybe move or copy it to that folder (depending on the available drop actions, and possibly also if it was dragged from another folder in the library). You can share an arbitrary file by calling RouterService.getFileManager().addFileAlways(File) . If you want notification if the file was succesfully shared or not, you can use addFileAlways(File, FileEventListener) and the listener will be notified upon success or failure. Files that aren't in a shared folder will be added to a 'Individually Shared Files' section of the library. I recommend having some sort of confirmation that the files are going to become shared. The confirmation becomes more difficult if it's multiple files that are dropped, but can be accomplished by listing the files and having some sort of checkbox next to each one.

Magnets links are a great idea for dropping (and applicable on all OS's actually). I'm sure there's a lot more things, so if you think of any other good ones, feel free to add'm in. :)

I *think* the best way to go about this (atleast for inter-LimeWire transfers) is to add a specific flavor to the drag & look for that flavor in the drop. That can take care of things like search results -> downloads, or recognizing when a file is being dragged from the library as opposed to from the desktop.

One other thing I experimented with a while ago (but never really got around to completing) was the ability to drag a search result into an IM window (or something of that nature) and having it drop a magnet link. It kinda/sorta worked, though I wasn't really happy with the way I went about doing it, so never committed the change. That'd be sweet to see in there.

[nomolos]

Alright, that's sounding good so far. I agree on the "flavour" idea - that's what I had come up with to make things easier when I was thinking about it, too. As for the search result -> window thing: it would be sweet to an IM window, and it'd probably be not to bad if we converted a dragged search result to a string containing the magnet link and just let the OS handle it - although maybe that's what you had started doing already.

[Sam]

Yeah that's kinda what I did, but I noticed that AIM was odd in that it required the drag to be a file and the contents of the drag to be the text it wanted to paste, so I ended up offering both a String flavor & a File flavor (creating a temporary file on the fly).

[fberger]

Hi,

sorry for the confusion, but there is already a development branch that provides most of the features. Here's a short description of the classes:

FileDropHandler: is installed for compontends and forwards file drops to a
class that implements the FilesHandler interface. Also handles linux specific
file flavor.

FileTransferHandler: Abstract class that subclasses the TransferHandler from
Swing to ease file transfers.

FilesHandler: Interface that handles a drop of files. Is called from the
FileDropHandler.

SharedFilesHandler: Asks if the dropped files should be shared and shares them.

MainFrame: a file drop handler is installed that asks if the dropped files
should be shared. This is also done for the other mediator tabs
(MonitorMediator, ConnectionMediator)

DownloadMediator: A special TransferHandler (private class MyTransferHandler)
is installed that handles search result drops and file drops as well. It also
handles drags of download objects creating a drag to the partially downloaded
file.

LibraryMediator: Also uses a special TransferHandler (private class
MyTransferHandler). It supports dragging of files and dropping of files.

LibraryTree: Allows dragging of folders, but looks like it needs work, still
has print statements.

PlaylistMediator: Special drop handler, that addes the dropped files to the
play list if they are supported. And also supports dragging of files.

FilterBox, UploadMediator: Uses standard shared files handler.

ResultPanel: Allows dragging of results to the download table.

DragListener: Adapted to use prefer handlers if the are installed.

FileTransferable: There's a TODO entry to create magnet links for the text flavor of the transferable.

You could bring it up-to-date, implement the missing features and TODO items and test it.

Thanks,
Felix

[Sam]

Just FYI, the branch's name is 'drop-file-support-branch'.

Sorry 'bout the confusion. I had completely forgotten that Felix had done some work on this earlier. :(

[nomolos]

Hi Sam,

Due to a new job and a lot of stuff going on in my life right now, I am going to pull the "in progress" label from this bounty, as I just don't have any time right now to work on it. Unfortunately, I don't really have any usable code for it right now either so I'll just leave the wiki page for the bounty as-is.

[Sam]

No worries. Good luck with the job!