Ticket #1627 (closed feature: moved)

Opened 6 years ago

Fix IconService architecture

Reported by: curtis Owned by: bdezonia
Priority: major Milestone: imagej-2.0.0
Component: UI Framework Version: 2.0.0-beta6
Severity: serious Keywords:
Cc: Blocked By:
Blocking:

Description

The IconService exists to make it possible to paint icons in a UI-agnostic way. Unfortunately, the current architecture has some problems:

  1. There is no default or dummy IconService implementation. So if something depends on IconService (via a compile-time dependency to ij-tool), but does not include another dependency with an actual concrete implementation, then it will not be possible to create an ImageJ context with an IconService. We avoid this issue in other cases by having a dummy service (e.g., with RenderingService) that performs no-ops.
  2. The architecture needs more consideration and testing with respect to UIs besides Swing, with multiple UIs, and when running without a UI. Right now, if you create a headless ImageJ context, the SwingIconService is still used for icon drawing, when it may not be the most appropriate solution. It may be simpler to integrate the icon drawing logic into the UIService and/or UserInterface interfaces more directly. Regardless, further thought is needed.

Change History

comment:1 Changed 5 years ago by curtis

  • Status changed from new to closed
  • Resolution set to moved
Note: See TracTickets for help on using tickets.