While we now have an ImageService that can use participants, it is limited to Images that can be identified by a String URL. This means it can't dynamically create new images, e.g. to support Visibility overlays.
A simple way to support overlays would be to let the ImageService add new Image instances to the ImageRegistry, with a custom key/url (e.g. a WritableImage created by stacking several existing images). This would only require an additional method in the ImageRegistry, without breaking any API, and keeping the ImageService API very simple.
We could also consider supporting more complex UI Nodes rather than just images; but that would probably require deeper changes to the ImageService.
At the very least, we want to be able to support overlays; with at least two use cases:
Visibility overlays for UML NamedElements (e.g. Property/Operation)
Validation marker overlays (Error/Warning displayed on top of the Element Icon)
This is a follow-up on #11
While we now have an ImageService that can use participants, it is limited to Images that can be identified by a String URL. This means it can't dynamically create new images, e.g. to support Visibility overlays.
A simple way to support overlays would be to let the ImageService add new Image instances to the ImageRegistry, with a custom key/url (e.g. a WritableImage created by stacking several existing images). This would only require an additional method in the ImageRegistry, without breaking any API, and keeping the ImageService API very simple.
We could also consider supporting more complex UI Nodes rather than just images; but that would probably require deeper changes to the ImageService.
At the very least, we want to be able to support overlays; with at least two use cases: