This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||Use Utilities.translate in IconManager (Utilities.loadImage)|
|Product:||platform||Reporter:||Jesse Glick <jglick>|
|Component:||-- Other --||Assignee:||issues@platform <issues>|
|Severity:||blocker||CC:||blee, issues, jtulach, pzavadsky|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:|
Description Jesse Glick 2002-10-23 19:52:52 UTC
I.e. pay attention to META-INF/netbeans/translate.names when loading images. This would permit modules to rearrange their icons during a refactoring without fear of breaking other modules which (illegally) refer to these icons, provided the other modules use loadImage as they should, rather than raw ClassLoader.getResource etc. More generally, there has been talk of an icon lookup API of some sort (using JNDI maybe?) that did not rely on classpath positions of images, but there was never consensus on how to do it in such a way as to make module evolution safe while maintaining UI consistency. It is a hard problem. This would just be a workaround. Ran into this problem recently - many modules were illegally using org/openide/resources/src/*.gif, which all got moved. Had to grep through sources to update references. One problem: current translate.names file only deals with class names, not resource names. In principle doing a package-wide translation should work anyway, by creating a fake class name (e.g. org/foo/bar.gif -> org.foo.bar), and icon-by-icon translations might even work the same way. It is a hack though. Rather than patching IconManager, it may work to patch Module.OneModuleClassLoader and/or ModuleManager.SystemClassLoader in core to override findResource to check the translation table. Might be a performance hit, though - TBD. (Doing such an automatic translation would not work for class loads. Class translation only works during deserialization using NbObjectInputStream.)
Comment 1 Jaroslav Tulach 2002-10-29 14:33:41 UTC
IconManager could try to load the original icon name and if fails, try the translated name. No performance hit for well written modules then.
Comment 2 Jesse Glick 2002-10-29 14:58:01 UTC
"IconManager could try to load the original icon name and if fails, try the translated name." - yeah, would probably work. Need to just check that I18N'd icon lookups don't add a performance hit - i.e. that if there is a lookup on an icon, its translated name, and all locale variants of both of the above, then the search goes in the correct order: all variants of original name, then all variants of translated name, then fail.