Community
Participate
Working Groups
Currently wherever the specifier needs to specify an image in the VSM, we use the ImagePath datatype, which is a fixed (not interpreted) string representing the path to an image file. There is some flexilibity in *where* the file will be looked-up (workspace or plug-in), but this is often not enough. See bug #500654 for example (there are others) which requests for these paths to be interpreted expressions. I think we could go even further. The rough idea would be to create an ImageExpression datatype, which would behave exactly like an interpreted expression, but would allow the result of the evaluation to be either: * a plain String: behave as with the current ImagePath (except that the path could have been computed); * a URI, either as a java.lang.String parseable as an EMF URI, or directly as a URI object. In that case it would be interpreted as the location of an image file (whether or not we want to support loading images from the network or only on platform:/ URIs is another subject); * an org.eclipse.jface.resource.ImageDescriptor instance: use that to create (and pool) the image to use; * an org.eclipse.swt.graphics.ImageData: use that to create (and pool) the image to use; * an actual org.eclipse.swt.graphics.Image: use that directly. The tricky part would be to track the lifecycle of the SWT Images created this way: how to avoid re-creating costly ImageData or Image on each expression invocation? when to dispose() the images? We could have an org.eclipse.jface.resource.ImageRegistry per session/representation/editor for that, and pass it as a variable to the expressions with some protocol to be used by services that need to create dynamic images.
