<div dir="ltr">Hi everyone (mostly core ImageJ2 and SCIFIO developers),<div><br></div><div style>I recently completed some work to make drag-and-drop extensible:</div><div style>    <a href="https://github.com/imagej/imagej/commit/9f20b3ec">https://github.com/imagej/imagej/commit/9f20b3ec</a></div>

<div style><br></div><div style>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.</div><div style><br></div><div style>Further, since then I have done a little bit more work on supporting various text formats:</div>

<div style>    <a href="https://github.com/imagej/imagej/commit/a34d1b2e">https://github.com/imagej/imagej/commit/a34d1b2e</a></div><div style>    <a href="https://github.com/imagej/imagej/commit/cb6e8b76">https://github.com/imagej/imagej/commit/cb6e8b76</a></div>

<div style><br></div><div style>There is now a TextFormat plugin type, for providing extensibility in dealing with text documents in various markup languages such as Markdown.</div><div style><br></div><div style>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).</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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.)</div>

<div style><br></div><div style>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).</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>Thoughts? Agree, disagree?</div><div style><br></div><div style>Regards,</div><div style>Curtis</div><div style><br></div></div>