NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #860 (closed feature: fixed)

Opened 2011-11-02T10:38:03-05:00

Last modified 2013-06-07T15:37:54-05:00

Make a UI agnostic drag and drop facility

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej2-b7-ndim-data
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By: #439, #846, #1675, #1677
Blocking: #9, #10, #1398, #1912


Drag and drop is currently implemented in the ij-ui-swing-base project. The code is adapted from IJ1 and does not have a very clean design. It also drags in lots of dependencies it shouldn't. We should have a ui-agnostic DropHandler facility that can be used in each ui implementation as needed. Barry, Curtis, and Johannes discussed this a bit in the imagejdev chat room and that log is included below.

Change History

comment:1 Changed 2011-11-02T10:41:24-05:00 by bdezonia

ctrueden: I'm trying to hatch a UI agnostic drag and drop class. it needs to do things like run IJ2 plugins, hatch BF readers, etc. So it has a number of dependencies. Originally I was going to put into imagej.ui.dnd but you probably don't want a ton of dependencies in there. Can you think of a home? Or should we make a new subproject: ij-dnd?

Why does it need to depend on BF at all?
That is supposed to be completely abstracted away in imglib2-io

If I may chime in: I could imagine that we'd need yet another sezpoz'able interface for DnD handlers.
So that you can, say, handle plugins being dropped on the main window, but not when the user uses File>Open.

That makes sense.

I determine if a dropped file is an image file by trying to create a reader. If the creation fails I try to open it as a known file type (such as .lut) and failing everything I open it in a text window.

I agree with dscho. Let's make it use dynamic discovery instead. That way your DnD handler can have "canHandle(String)" or "isRelevant(String)" or whatever type of object the DnD provides. And the first available DnD handler that says "yes I support this" takes care of it.
Otherwise we'll end up with another "HandleExtraFileTypes" implementation in core.

Probably you need to pass the MIME type, too...

Okay. So it's own subproject? ij-dnd?

(Java's DnD delivers that, and it is quite handy)
If you make a new interface, I don't think that a new subproject is necessary.
That interface can live quite centrally.
(Probably accompanied by a Service...)

yes, the interface can live in ij-ui. but the implementation(s) need to live somewhere that can have other dependencies.

I am not convinced that the core DnD implementation(s) needs to live outside. Like you said, it depends on the dependencies.
We should *not* depend on BF.
We need a way to ask ImageJ "is this an image?" without invoking BF.
This is part of the "redesign I/O infrastructure" ticket.
For now, to determine if it's an image, can't you just call OpenImage on it, and catch exceptions?
And if that fails, then move on.

The plugin don't throw exceptions (!??!)
I could be calling it wrongly

is wondering whether ij-io can get a class that implements DnDHandler (sezpoz-annotated)...

Looking at the OpenImage code, it is not modular enough.
In run it does a few things, all wrapped in try/catch.
Instead, we could have a method that does those things and throws exceptions. Then in run just call that method.
Then you would have a hook to call it with exception handling.
dscho: We could make ij-io work that way… but I think the other way 'round makes more sense.
Eventually we will have an IOPlugin, and perhaps an IOService.


Then the DnD handler that tries to determine if the dropped thing is an image can just ask the IOService.

Reusable by others, too. Makes sense.

So, Barry, then the image DnD handler can live in ij-io.


If you want to get started on this architecture, that's great. We can keep discussing details as needed. But it's probably not the most urgent for beta1. So maybe file a ticket instead, and link it to ticket #9, with milestone beta2.

And any DnD-related tickets can be pushed to beta2 and linked to the new ticket as a blocker.

comment:2 Changed 2011-11-02T11:48:27-05:00 by bdezonia

TODO reminder: remove dependency on ij-io from ui-swing pom.xml when this code refactoring is done

comment:3 Changed 2012-02-26T21:48:47-06:00 by curtis

  • Blocked By 853 added

comment:3 Changed 2012-02-26T21:49:51-06:00 by curtis

  • Type changed from defect to feature
  • Blocking 9, 11 added
  • Blocked By 853 removed

comment:4 Changed 2012-02-26T21:50:18-06:00 by curtis

  • Blocked By 853 added

comment:5 Changed 2012-02-26T21:50:37-06:00 by curtis

  • Blocked By 846 added

comment:6 Changed 2012-02-26T21:53:30-06:00 by curtis

  • Blocked By 439 added

comment:4 Changed 2012-02-26T21:55:30-06:00 by curtis

  • Blocking 10 added

comment:5 Changed 2012-03-05T14:43:25-06:00 by curtis

  • Blocking 1051 added; 11 removed

comment:6 Changed 2012-04-13T12:10:45-05:00 by curtis

The IOService mentioned above was added in 680ff07bc60364174d34fbefa081603ed4b530a9, which will help facilitate the drag-n-drop infrastructure in the future.

comment:7 Changed 2012-05-14T11:00:21-05:00 by bdezonia

  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

comment:8 Changed 2012-05-15T09:41:19-05:00 by curtis

  • Blocking 1052 added; 1051 removed

comment:9 Changed 2012-08-03T10:03:18-05:00 by bdezonia

  • Blocking 1340 added

comment:10 Changed 2012-09-06T14:10:03-05:00 by curtis

  • Blocking 1357 added; 1052 removed
  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5

comment:11 Changed 2012-09-07T11:11:52-05:00 by bdezonia

  • Blocking 1398 added; 1340 removed

comment:12 Changed 2013-03-03T17:21:52-06:00 by curtis

Lots of progress on the  drag-and-drop branch. Just need to finish implementing the various DragAndDropHandler plugins! Comments welcome.

comment:13 Changed 2013-03-07T16:00:30-06:00 by bdezonia

  • Status changed from new to reviewing

comment:14 Changed 2013-03-13T15:01:27-05:00 by bdezonia

  • Blocked By 1673 added

comment:15 Changed 2013-03-14T10:00:22-05:00 by bdezonia

  • Blocked By 1674 added

comment:16 Changed 2013-03-14T10:21:28-05:00 by bdezonia

  • Blocked By 1674 removed

comment:17 Changed 2013-03-14T10:21:49-05:00 by bdezonia

  • Blocked By 1673 removed

comment:18 Changed 2013-03-14T10:27:28-05:00 by bdezonia

  • Blocked By 1677 added

comment:19 Changed 2013-03-14T14:29:54-05:00 by bdezonia

  • Owner changed from bdezonia to curtis

Code reviewed and extended by bdezonia and ctrueden. ctrueden has the ball in his court at the moment.

comment:20 Changed 2013-03-14T14:35:00-05:00 by bdezonia

Note that TODO reminder above about ij-io taken care of on drag-and-drop branch. Just waiting to be merged.

comment:21 Changed 2013-03-19T10:59:18-05:00 by curtis

  • Blocking 1357 removed

comment:22 Changed 2013-04-15T10:01:40-05:00 by bdezonia

  • Blocked By 1675 added

comment:23 Changed 2013-04-15T10:33:54-05:00 by curtis

Lots more progress on the  drag-and-drop branch. All compiles, but there are still bugs. Once those are solved and merged, this feature will be much closer to completion.

comment:24 Changed 2013-04-15T10:34:21-05:00 by curtis

  • Status changed from reviewing to accepted

comment:25 Changed 2013-04-16T17:01:18-05:00 by curtis

  • Blocked By 853 removed

(In #853) I am migrating this ticket to the b10-compatibility milestone (feature ticket #1821). However, it would still be good to split the list above into separate tickets, and then close this one as a duplicate.

comment:26 Changed 2013-04-16T17:02:42-05:00 by curtis

  • Status changed from accepted to closed
  • Resolution set to fixed

With the merger of the drag-and-drop branch and related improvements, this feature is complete.

comment:27 Changed 2013-06-05T15:12:09-05:00 by bdezonia

  • Blocking 1912 added; 9 removed

comment:28 Changed 2013-06-07T15:37:54-05:00 by curtis

  • Blocking 9 added

(In #9) This ticket is really about improving the infrastructure if I/O for ImageJ2. With SCIFIO, we have now done that. The 2.0.0-beta-7 release is using SCIFIO 0.1.0—File Open and File Save are now extensible—so this ticket is complete.

Remaining tickets about improving the existing I/O mechanism have been migrated to ticket #1920.