[ImageJ-devel] Questions about recent I/O and drag and drop work

[Curtis Rueden]

Hi everyone (mostly core ImageJ2 and SCIFIO developers),

I recently completed some work to make drag-and-drop extensible:
    https://github.com/imagej/imagej/commit/9f20b3ec

It is now possible to define a new DragAndDropHandler plugin for dealing
with an arbitrary MIME type and/or Java class, which is pretty nice.

Further, since then I have done a little bit more work on supporting
various text formats:
    https://github.com/imagej/imagej/commit/a34d1b2e
    https://github.com/imagej/imagej/commit/cb6e8b76

There is now a TextFormat plugin type, for providing extensibility in
dealing with text documents in various markup languages such as Markdown.

Also, the IOService now has a generic "Object load(File)" method that is
intended for use by the ImageJ UI's File Open command (which now resides in
the OpenFile class).

However, doing all this has led me to the conclusion that the drag-and-drop
work is a little mis-structured. Dragging and dropping *any* files onto
ImageJ should, if there is no higher priority DnD handler available, just
call IOService#load(File) on them, since it is intended to be the
high-level entry point. Of course, we can also provide higher priority
handlers to do things like apply a LUT to the image onto which it was
dragged. But the fallback case should be "just open the file as though it
had been chosen via File Open." We want to avoid a scenario where
drag-and-drop of a file works, but File Open does not.

If so, this means getting rid of ImageFileDragAndDropHandler,
ScriptFileDragAndDropHandler and part of LUTFileDragAndDropHandler in favor
of a single DefaultFileDragAndDropHandler which calls IOService#load on the
files. (We would still need the LUTFileDragAndDropHandler, but only to
handle the case where a LUT was dragged onto an image display specifically.)

However, if we go that route, extensibility of IOService#load must then be
solved in a similar fashion. We should have a new IOHandler, which provides
handling of Files (and maybe other data sources such as URLs?) of various
types. At first glance, this may seem dangerously close to reinventing
SCIFIO again... but the difference is that SCIFIO only handles image data.
The IOHandler would be simpler than SCIFIO, but also more general, allowing
total extension of IOService#load (and hence the File Open command).

In the case of scripts, some reconciliation with the scripting framework
will be necessary, because right now, the Script Editor is not a Display.
That is, there is no type of Java object that IOService#load can return
when opening a script that results in a Script Editor window popping up to
display/edit it. But I believe this can be addressed.

Thoughts? Agree, disagree?

Regards,
Curtis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130418/29542de9/attachment.html>