⚠

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 #995 (closed feature: fixed)

Opened 2012-02-22T14:07:58-06:00

Last modified 2012-05-17T13:46:30-05:00

Headless displays

Reported by: curtis Owned by: curtis
Priority: critical Milestone: imagej2-b2-bugfixes
Component: Display API Version:
Severity: major Keywords:
Cc: Blocked By: #616
Blocking: #10, #660, #884, #936

Description

Displays need to become fully UI-agnostic. It should be possible to say e.g. "new DefaultImageDisplay()" to create a display (and similarly for DatasetViews and OverlayViews). The display itself should not be tied to any UI components. Rather, the UIService listens for DisplayEvents generated by Displays and creates/updates/removes linked UI components such as DisplayPanels and DisplayWindows. In this fashion, plugins can work with Displays without any dependence on specific UI(s).

Some specific needed changes:

  • Eliminate Display.getPanel method
  • Eliminate ImageDisplay.makeLabel method
  • DisplayPanels/DisplayWindows must be managed by UIService and similar

Some related design details discussed here:

 http://developer.imagej.net/2011/09/29/display-framework-changes

Change History

comment:1 Changed 2012-02-26T21:37:08-06:00 by curtis

  • Blocked By 616 added

comment:1 Changed 2012-02-26T21:37:13-06:00 by curtis

  • Type changed from defect to feature
  • Blocked By 616 removed

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

  • Blocked By 616 added

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

  • Blocking 10 added

comment:4 Changed 2012-03-27T11:56:45-05:00 by curtis

  • Blocking 936 added

(In #936) I don't think so. The SelectWindow plugin calls display.activate(), which does fire, but the corresponding window is never selected. Rather, I think finishing the display refactoring (#995) will address this issue.

comment:5 Changed 2012-03-27T11:57:36-05:00 by curtis

  • Blocking 884 added

(In #884) Finishing ticket #995 will help address this issue.

comment:4 Changed 2012-03-28T14:14:21-05:00 by leek

I would like to have a generic UI service that could find the appropriate viewer for a view. The UI service would listen for display created events and use a sez-pos mechanism to find viewers capable of viewing displays.

The partition removes the ImageCanvas from ij-data. The DefaultImageDisplay becomes a bag that holds DataViews. The DisplayService creates displays without the help of sez-pos - DisplayService.createDisplay creates a DefaultImageDisplay. DefaultImageDisplay.display() creates DefaultImageViews or DefaultOverlayViews.

A viewer would use something like the current three-part discovery and instantiation process:
DisplayViewer.canDisplay(Display) is used to find the first viewer that can handle the display.
DisplayViewer() creates an instance
DisplayViewer.setDisplay(Display) associates viewer and display.

There's only so many words for things like "Display" and "Window" and, if possible, you don't want to shake the tree by renaming everything. So "Viewer" is maybe not the best word for the UI component, but it is distinct from Display, Window and View and it means "something that looks at a view" which is not that far from the truth.

After this, DisplayViewer listens for events on the display and its views in order to repaint and relayout.

comment:5 Changed 2012-04-26T09:14:08-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to fixed
  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta2

Lee developed this work on a branch which has now been merged as 96adb4f7790e4b7ee2a90581715887cd90343a6a through c0985c4668cfa2751829951f5aaa2d237ca34464.

The API is still not completely finalized, and will be further polished moving forward, but it currently addresses the major issues described here, so this ticket is closed!

comment:6 Changed 2012-05-17T13:46:30-05:00 by curtis

  • Summary changed from Separate core Display class hierarchy from UI implementations to Headless displays