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.

Bug 28227

Summary: Use Utilities.translate in IconManager (Utilities.loadImage)
Product: platform Reporter: Jesse Glick <jglick>
Component: -- Other --Assignee: issues@platform <issues>
Status: NEW ---    
Severity: blocker CC: blee, issues, jtulach, pzavadsky
Priority: P3 Keywords: API
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 19443    

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.