Community
Participate
Working Groups
Context: in my .design, the palette contains several creation tools, all pointing to the same mapping (an abstract graphical node definition). The creation instruction sequence creates the graphical node, then creates a semantic element and links it to the graphical node. I want the palette to display the icon related to the semantic element referenced by the graphical node nor than the icon related to the graphical node (because there is none). Problem: I cannot use the "icon path in creation tool" way because I have no path for my icons: they are generated in a label provider depending on preferences. When the icon path is not specified, by default Sirius instantiates the referenced mapping of each creation tool, then gets the correct image for it. When the label provider (of graphical node) is called, as it has just been instantiated it doesn't reference the semantic element yet. So the label provider, not knowing which creation tool was called, cannot return the right icon. The only workaround I found was to add in my metamodel a sub graphical node concept for each semantic concept, that I can reference in the creation tools. I then redefined the .edit of the metamodel to lead to the right image computation for those nodes (returning the generated image). This is quite heavy and complex to maintain. It would be easier if there was a way to specify in the .design not the icon path, but point to a java service returning the Image or ImageDescriptor.
More generally, we could investigate having all "icon path" be interpreted expression which could return: - a String (interpreted as a path, exactly as in the current behavior); - an actual JFace ImageDescriptor (returned by a service invoked in the expression); - an actual SWT Image (returned by a service invoked in the expression); - maybe other types (e.g. URI)? The only obvious issues I see concerns the lifecycle of the ImageDescriptor and Images returned: - Who would be responsible for disposing them and when? - How would an expression which returns a full Image avoid re-creating a new one on each invocation (which can happen very often)? One approach could be to expose an Image(Descriptor)Registry as a variable available to the expression. It could be passed to the Java service (e.g. "service:computeToolIcon(registry)"), which could then first look for an already existing image under a given (provided or computed) key, and return that instead of creating a new one if found. This could also help solve the lifecycle issue, as we could scrub the registry ourselves (for example have a local registry for each diagram editor for its palette icons, and dispose the registry when the editor is closed or some similar policy). I'm not sure of the performance implications, but it could be worth investigating.
