Bug 28227 - Use Utilities.translate in IconManager (Utilities.loadImage)
Use Utilities.translate in IconManager (Utilities.loadImage)
Status: NEW
Product: platform
Classification: Unclassified
Component: -- Other --
3.x
All All
: P3 (vote)
: TBD
Assigned To: issues@platform
issues@platform
: API
Depends on:
Blocks: 19443
  Show dependency treegraph
 
Reported: 2002-10-23 19:52 UTC by Jesse Glick
Modified: 2009-01-06 15:01 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo