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: |
|
| Component: | Core | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | #439, #846, #1675, #1677 | |
| Blocking: | #9, #10, #1398, #1912 |
Description
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
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:49:51-06:00 by curtis
- Type changed from defect to feature
- Blocking 9, 11 added
- Blocked By 853 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: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: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: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: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:25 Changed 2013-04-16T17:01:18-05:00 by curtis
- Blocked By 853 removed
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: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.
10:02
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?
10:04
ctrueden
Why does it need to depend on BF at all?
That is supposed to be completely abstracted away in imglib2-io
10:05
dscho
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.
10:07
ctrueden
That makes sense.
10:07
bdezonia
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.
10:08
ctrueden
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.
10:09
dscho
Probably you need to pass the MIME type, too...
10:10
bdezonia
Okay. So it's own subproject? ij-dnd?
10:10
dscho
(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...)
10:12
bdezonia
yes, the interface can live in ij-ui. but the implementation(s) need to live somewhere that can have other dependencies.
10:13
ctrueden
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.
10:14
bdezonia
The plugin don't throw exceptions (!??!)
I could be calling it wrongly
10:15
dscho
is wondering whether ij-io can get a class that implements DnDHandler (sezpoz-annotated)...
10:15
ctrueden
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.
10:16
dscho
Ah.
10:17
ctrueden
Then the DnD handler that tries to determine if the dropped thing is an image can just ask the IOService.
10:17
dscho
Reusable by others, too. Makes sense.
10:18
ctrueden
So, Barry, then the image DnD handler can live in ij-io.
10:18
bdezonia
sure
10:19
ctrueden
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.
10:20
ctrueden
And any DnD-related tickets can be pushed to beta2 and linked to the new ticket as a blocker.