Ticket #1674 (closed defect: wontfix)

Opened 7 years ago

Last modified 5 years ago

Drag And Drop should score translations

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej2-b8-analysis
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1676

Description

On the drag-and-drop branch there is code for supporting drag and drop in a platform independent fashion. One limitation is that it translates data using the first compatible translation it finds. These translations are found by searching the DragAndDropHandlers in their priority order. However as 3rd parties add drag and drop support this priority order may get in the way.

An example where this is tricky is if one tries to past spreadsheet cell data (for instance from NeoOffice). In the future we might have a translator that translates html tables of numbers to a results table. This pasted data says it can be text/html table or it can be text/plain. Depending upon the priority of the handlers one will be done over the other. With more handlers this could get unwieldy.

Ideally we would have each DragAndDropHandler score how well it supports a mime type. Then we choose the best translator (DragAndDropHandler reference and mime-type) from all installed translators. This would allow 3rd parties to override anything they wanted without have to jockey for position in the priority queue.

Change History

comment:1 Changed 7 years ago by bdezonia

  • Blocking 1676 added; 860 removed
  • Milestone changed from imagej2-unscheduled to imagej2-b8-analysis

comment:2 Changed 7 years ago by bdezonia

ctreuden made the comment that we should look at Java's DataFlavor class, understand its complexity, and apply such knowledge to our design.

comment:3 Changed 6 years ago by curtis

In your example above, couldn't you just split the NeoOfficeSpreadsheetHandler into two separate handlers, one for text/html and one for text/plain, if those two things really need to be different priorities? Of course, they could share a common base class to keep the code DRY.

Last edited 6 years ago by curtis (previous) (diff)

comment:4 Changed 5 years ago by curtis

  • Status changed from new to closed
  • Resolution set to wontfix

It is always possible to simulate a "scoring" mechanic by splitting a handler into one handler per unique "score" it might assign. While there may be use cases where using multiple handlers in such a fashion becomes unwieldy, let's wait until we come across such a case before complexifying the drag and drop design.

Note: See TracTickets for help on using tickets.