Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix IconService architecture #56

Open
ctrueden opened this Issue May 6, 2014 · 0 comments

Comments

Projects
None yet
1 participant
@ctrueden
Copy link
Member

commented May 6, 2014

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, 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.

Migrated-From: http://trac.imagej.net/ticket/1627

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.