Community
Participate
Working Groups
Target for 3.1.1 release (NL release). In Eclipse 3.1, icons are being supplied for BiDi locales that will appear as if the icon has been reversed. For all plugins that supply icons, some code changes are required to support this that do not appear to be present when running Eclipse in a BiDi locale (get BiDi fragments then run Eclipse with program argument -nl ar_EG). The following 2 items need to be checked: 1. Paths to icons/images that can appear flipped must be prefixed with $nl$/ (e.g. $nl$/ICON_PATH) - this includes paths to icons and images in plugin.xml. 2. Must use Platform.find(Bundle, Path) to create the URL that is used to create the image descriptor. See Tod's Eclipse blog entry for more details on the code changes required. http://todcreaseyeclipse.blogspot.com/ NOTE: Only icons that have the possibility of being flipped need to have this prefix added - you can leave the paths of other icons as they are for 3.1.1 if you want to keep changes to a minimum. You can get the BiDi nl fragments from Cam-Thu Le so that you can see which of your icons have a reversed counterpart in BiDi locales. The following plugins of this component have been identified as requiring this check: *org.eclipse.ltk.ui.refactoring *org.eclipse.jdt.ui Questions about this issue can be directed to Karice McIntyre or Tod Creasey.
Created attachment 25352 [details] patch
(attachment 25352 [details] is patch for jdt.ui)
The patch comment indicates that it is for jdt.ui. Is another patch required for ltk.ui.refactoring, or are both areas covered by the existing patch?
No, LTK needs a separate patch I am working on right now.
Created attachment 25356 [details] Patch for LTK
Thanks, Dirk. Are going to take care of getting these released?
Yes.
Created attachment 25359 [details] Modified patch for JDT/UI.
Martin, can you please look at the modified version of the JDT UI patch and at the LTK patch. Tom, can you please review the LTK and JDT/UI patch.
LTK patch reviewed, ok.
LTK patch looks good. JDT-UI Patch looks ok to me, but I see the following behavioral change when the contributor to the wizard extension point specifies a path to a non existing icon: Before: An ImageDescriptor is returned, that would return null in getImageData, which causes the action to have the missing image (red square). After: We return null, which causes the action to have *no* image. Not a big change, but not really needed either for a maintenance build...
... and arguably, it's better to have the red square, which calls out the fact that the icon is missing.
Tom is right. ImageDescriptor.createFromURL(url) never returned null but an image descriptor that would render a 'missing' image for an unknown location. Only for the very rare occasions of MalformedURLExcepions we would return return somtimes null. That means that the null checks in our old code where not really useful. The updated patch fixes that and also restores the original intention to not set the disabled images if none could be found.
Created attachment 25396 [details] updated path for jdt.ui Tom, Dirk, can you review again?
Created attachment 25397 [details] patch for jdt.junit For completness a path for jdt.junit (still without plugin.xml which we can only hcnage when we are sure all components have updated their code). Dirk, Tom?
Created attachment 25398 [details] patch for jdt.ui.examples.projects and for jdt.ui.examples.projects...
Created attachment 25400 [details] Updated LTK patch to follow the same schema Tom, Martin, can you please have a look.
reviewed patches for jdt-ui, ltk-ui, jdt-junit and jdt.ui.examples, ok.
JDT/UI patch looks ok for me. When releasing to 3.2 we should rename create(String prefix, String name) to createUnManged to make it clear that it is a counterpart to createManaged and should use create(..., boolean) inside of JavaPluginImages.
jdt.ui.examples patch is OK. jdt.junit patch: - ProgressImages: the field fMissingImage is no longer needed since it will never be unequal null now. The 3.1 we only had one missing image which was shared. Now we have one for every image that is missing. Since this should normally not happen the change is ok.
added fix suggested in comment 20, released to 3.1.1 stream: jdt.junit, jdt.ui.examples.projects, jdt.ui added fixes suggested in comment 19 and comment 20 and released to 3.2 stream: jdt.junit, jdt.ui.examples.projects, jdt.ui LTK patch looks good to me, ok to release.
Released changes to LTK/UI plug-in.
In both 3.1.1 and 3.2 stream.
Are all the fixes released to both 3.1.1 and 3.2 streams for all the affected plugins (I think more plugins than were originally identified were added to the list, like junit, etc). Can we mark this bug as resolved?
As discussed in the planning call the fixes must be staged. We have released the code changes but not the plugin.xml changes since they require that all code changes are in for downstream plug-ins for JDT/UI. If all code changes in downstream plug-ins are done for tomorrows maintenance build we can release the plugin.xml changes as well for tomorrow. Otherwise we have to old them off since icons will be missing.
Same is true for integration build.
Note: The team and cvs plugins have not been updated yet, since Michael Valenta is on vacation until tomorrow.
JDT/UI is only depending on team.core which can't have any icon extension point. So this should be fine.
We have updated and releases the plugin.xml files as well. Marking as fixed.
Start verifying...
Verified in M20050804-1200 and I20050808-2000 that icons in org.eclipse.jdt.junit org.eclipse.jdt.ui.examples.projects org.eclipse.jdt.ui org.eclipse.ltk.ui.refactoring are nl-aware.
