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 #1627 (closed feature: moved)

Opened 2013-01-18T13:47:43-06:00

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:


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 2014-05-06T08:23:48-05:00 by curtis

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