Community
Participate
Working Groups
ImageDescriptor desc = ImageDescriptor.createFromURL(null); Image image = desc.createImage(false); It seems like this should return a null image, rather than the missing image.
I agree with Randy - desc.createImage(false) is spec'd to return null if the image cannot be created.
The inconsistency occurs because ImageDescriptor.createFromURL always returns an image descriptor describing the missing image. The spec for the constructor is vague. It doesn't say that null can be returned, but it doesn't explicitly say that the descriptor for the "missing image" is returned. By the time you call createImage, you already have a descriptor describing the missing image, so of course the image can be created. I don't see changing the behavior for createFromURL(URL) because clients are likely relying on this. But if needed we could add a constructor that includes a parameter that lets you specify whether you want the missing image or not. Either way we should tighten up the javadoc for createFromURL(URL) to be more specific about what it does.
The implementation class MissingImageDescriptor is representing an error condition. The API ImageDescriptor#createImage(boolean returnMissingImageOnError) allows the caller to decide if error conditions should be shown in the UI. If I say FALSE, then I don't want the user to see red squares in the UI. The way that ImageDescriptor#createFromURL(url) behaves is not relevant to code that is handling only ImageDescriptors that have been created by someone else. In another scenario, the URL may not be NULL, but it may fail to load for some other reason. In that case the user does not see the red square. > By the time you call createImage, you already have a descriptor > describing the missing image, so of course the image can be created. But, I'm saying return anything except for the "missing image". It must return NULL, since that is the contract for all ImageDescriptors.
let me try again. I'm not sure which one of us is missing the point. The first line of code in your snippet is ImageDescriptor desc = ImageDescriptor.createFromURL(null); It so happens (though not spec'ed clearly) that if you supply a null URL, this method will return the missing image descriptor. You can say that's a bug, but the spec is fuzzy and it's unlikely we would change the behavior. We should update the spec and could potentially add an API that lets you specify with a boolean parameter whether you want the missing image descriptor to be used if the image descriptor cannot be created. But as is, your variable desc holds an instance of MissingImageDescriptor. Yes, it's an implementation class, but it's a legitimate image descriptor. Now you execute: Image image = desc.createImage(false); The false parameter indicates that if there is an error, don't return a default. But there's no error by this time. The image descriptor creates the image, and the fact that the receiver is the missing image descriptor doesn't change the fact that there was no error in creating its image. The only way to change this behavior would be to special case the image descriptor code so that if the receiver is the missing image descriptor, it behaves differently. That seems odd to me. Am I missing something?
one more thing...if you are suggesting that MissingImageDescriptor override createImage(boolean), createImage(boolean, Device) so that null is always returned, then we would have to spec that as such and make sure that there is still a way for callers to actually get an image when that is what's intended.
desc.createImage(false) == give me an Image that is not a red square, or NULL
I understand, but desc is the descriptor for the red square. So you are saying... desc.createImage(false) == give me an Image that is not a red square, or NULL, even if I'm asking the red square image descriptor for its image. That last part is what is a bit strange.
Given that MissingImageDescriptor is a "special" ImageDescriptor, it could just override createImage(boolean, Device) to always return null if the given boolean is false.
yes, this can be done, with the caveats in comment #5. We would need to fix any places in the framework that may inadvertantly rely on the old behavior (change uses from false to true when the missing image descriptor is being manipulated for display purposes), and realize that we may introduce NPE's in any client code that has the same assumption. at any rate, marking for 3.3 so that we look at this.
MissingImageDescriptor is a package protected class. All consumers of ImageDescriptor API should already be handling NULL when calling this method.
I do not disagree with anything that's been said here (don't really have an opinon) but, I can't help bug ask, just out of my ceaseless curiosity ... what problem is being solved here? I'm sure its obvious to all you specialists :) but ... its not to me, so, hope you don't mind me asking for the education. Thanks
Randy can comment on the specific use case, but my understanding of his problem is that he is using the ImageDescriptor.createImage(false) under the assumption that no "missing image squares" appear anywhere in his app. He desires to handle missing images in some different way. The "hole" he found in the JFace API is that there's no way to specify that you don't want the missing image square when you create a descriptor from a null URL.
I'm trying to load image files using multiple extensions ("gif", "png", etc.), until I find the Image for a filename. It's avoidable in many cases but it still seems like a minor inconsistency that is easily fixed.
No spec changes at this point. These bugs tend to lie around until it's too late to do anything, so I'm adding API to the bug title so this will stand out better for the 3.4 triage.
This message is part of a mass update...the bug is likely legitimate, but not a priority. Marking P5. Patches would be entertained.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
