triggering of org.scijava.ui.dnd.DragAndDrop* mechanism

[xulman]

Hi,

I propose to explicitly trigger the IJ2 DragAndDrop mechanism to allow developers more flexible (and modern) registration of their handlers of drag-and-drop events. I have empirically determined the last resort in the chain of the already established handlers, the last moment before the "universal" IOService::open() takes care of the incoming file or folder. Indeed, the open() hardly never fails to open whatever is dropped onto the Fiji window.

I also believe the IJ2 mechanism is not triggered anywhere before this IJ1 code, see below the call trace:

(sorry, I took screenshot instead of cut&paste)

Cheers,
Vlado

[xulman]

And here's the example of user-land drag-and-drop handlers:

package cz.ulman.dnd;

import org.scijava.display.Display;
import org.scijava.plugin.Plugin;
import org.scijava.ui.dnd.AbstractDragAndDropHandler;
import org.scijava.ui.dnd.DragAndDropHandler;

@Plugin(type = DragAndDropHandler.class) //possible option: priority = Priority.NORMAL
public class DropDragString extends AbstractDragAndDropHandler<String>
{
	@Override
	public boolean supports(final String file) {
		if (file == null) return false;

		//refuse to handle if outside my responsibility scope
		if (!file.endsWith(".vu")) return false;

		return true;
	}

	@Override
	public boolean drop(final String file, final Display<?> display) {
		//process the 'file' and signal if it went well
		return true;
	}

	@Override
	public Class<String> getType() {
		return String.class;
	}
}

[ctrueden]

@xulman I believe the DragAndDropHandler plugins are only functional for the imagej-swing user interface, not the imagej-legacy UI. The best place to add support for processing SciJava DragAndDropHandlers might be the interceptDragAndDropFile method of DefaultLegacyHooks, or potentially a new LegacyOpener plugin in imagej-legacy that delegates to the DragAndDropService. However, I notice that interceptDragAndDropFile assumes you are dropping a file—what about other objects? Does original ImageJ offer any support for dropping anything besides files? Do we want to do so?

@xulman What kind of drag-and-drop handling do you want to perform that cannot be covered by an IOPlugin?

[xulman]

@ctrueden Thank you very much for such quick reply.

IOPlugin: I didn't know about it. Tested it now, works well. Would live happily with it but... my use case is to open "3rd party" application like Mastodon, BDV, or own dialog (upon drag-dropping .zarr that queries further details what should be opened from the big .zarr) -- all of which are not "data", it's rather an "application" that is created (not even should it be really returned). The IOPlugin, considering the 'I' now only, requires some data to be provided to Fiji (which makes perfect sense, it's Input/Output afterall).

I could probably figure out some "innocent" return object that Fiji will not care about (at least will not trigger any exception, dialog, whatsoever) and use the iOService but that's probably what we don't want.

Hmm...
Perhaps the IOService could offer special object like IOService.APPTRIGGERED that clients like me would be returning ("opening") in such cases, and IOService (or its caller) would know it is something it shall not pass further.... Comes to philosophical question: is dropping .mastodon file onto Fiji window reading of a file (implemented via some 3rd Fiji app) or is it request for opening the app itself? Maybe the former, since I don't intend just to open the app, but rather open it already on the dropped file...

[xulman]

I could probably figure out some "innocent" return object that Fiji will not care about (at least will not trigger any exception, dialog, whatsoever) and use the iOService but that's probably what we don't want.

Here's an example of drag&drop loading of .mastodon files by abusing(?) the IOPlugin system. Note the example returns the "innocent" data.

I'm actually fine with such solution...

However, for better world: I will have a look how difficult would it be to pursue:

Perhaps the IOService could offer special object like IOService.APPTRIGGERED

[xulman]

I'm taking back this pull request in favor of two others:

• IOService recognizes a new 3rd state of loading data scijava/scijava-common#430 -- recognizes a 3rd state of opening
• avoid opening data that was already opened in 3rd party opener #18 -- adjust its behavior when the 3rd state is detected