Ticket #860 (closed feature: fixed)

Opened 8 years ago

Last modified 6 years ago

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

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 8 years ago by bdezonia

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.

comment:2 Changed 8 years ago by bdezonia

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

comment:3 Changed 8 years ago by curtis

  • Blocked By 853 added

comment:3 Changed 8 years ago by curtis

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

comment:4 Changed 8 years ago by curtis

  • Blocked By 853 added

comment:5 Changed 8 years ago by curtis

  • Blocked By 846 added

comment:6 Changed 8 years ago by curtis

  • Blocked By 439 added

comment:4 Changed 8 years ago by curtis

  • Blocking 10 added

comment:5 Changed 8 years ago by curtis

  • Blocking 1051 added; 11 removed

comment:6 Changed 8 years ago 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 7 years ago by bdezonia

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

comment:8 Changed 7 years ago by curtis

  • Blocking 1052 added; 1051 removed

comment:9 Changed 7 years ago by bdezonia

  • Blocking 1340 added

comment:10 Changed 7 years ago by curtis

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

comment:11 Changed 7 years ago by bdezonia

  • Blocking 1398 added; 1340 removed

comment:12 Changed 7 years ago 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 7 years ago by bdezonia

  • Status changed from new to reviewing

comment:14 Changed 7 years ago by bdezonia

  • Blocked By 1673 added

comment:15 Changed 7 years ago by bdezonia

  • Blocked By 1674 added

comment:16 Changed 7 years ago by bdezonia

  • Blocked By 1674 removed

comment:17 Changed 7 years ago by bdezonia

  • Blocked By 1673 removed

comment:18 Changed 7 years ago by bdezonia

  • Blocked By 1677 added

comment:19 Changed 7 years ago 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 7 years ago 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 7 years ago by curtis

  • Blocking 1357 removed

comment:22 Changed 7 years ago by bdezonia

  • Blocked By 1675 added

comment:23 Changed 7 years ago 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 7 years ago by curtis

  • Status changed from reviewing to accepted

comment:25 Changed 7 years ago 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 7 years ago 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 6 years ago by bdezonia

  • Blocking 1912 added; 9 removed

comment:28 Changed 6 years ago 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.

Note: See TracTickets for help on using tickets.