Community
Participate
Working Groups
email from MVM - Have you considered implementing the image loaders and image loading code using some sort of factory? Currently tools like SmartLinker can not remove image loader classes even if they are not used because they are all referred to in the big if statement that tests for what type of image is represented by the bytes in the stream passed in. This is just a suggestion and it means that for example when I build an SWT jar for MIDP, it will only contain the PNG image loaders and not jpeg/gif.etc.. NOTES: MCQ (5/30/2001 10:45:39 AM) Actually, the "big if statement" *is* a factory. ;-) But I understand what you mean. CM can look at doing some more disconnected way of refering to them after the Eclipse ship. McQ (26/06/2001 2:15:23 PM) - CM to investigate.
PRODUCT VERSION: 113
Chris, Isn't this fixed already?
We have removed the hard coded dependency on the image decoders, using Class.forName and well known list of image formats to form the class name of a decoder. Right now (v2106), you can remove image decoders. However, they will still be looked upon, found missing, which is not optimal. Really supporting (un) pluggable image file formats requires new api. New API proposal: ImageLoader save(OutputStream, String format, String properties) ImageData[] load(InputStream, String format, String properies) Where the String properties specifies the list of formats to look upon. File formats are comma separated. If the name contains a '.', then it must be a full package/class name. Otherwise it must be the prefix to an SWT file format decoder (BMPFileFormat etc...). Otherwise throws an IllegalArgumentException. "BMP,GIF,org.eclipse.mypackage.myformat"
File formats can be removed. SWT now remembers which ones are missing.
