Reassigning to Tomas for evaluation.

Created attachment 62547 [details]
API changes (org.openide.util.Utilities)

Proposed solution, see Utilities API changes in attachment.

What's the intended appearance of tooltips explaining icon badges?

[JG01] It is hard to evaluate this change without seeing at least some example changes to modules which would use it
productively.

[JG02] What is image2Icon good for, beyond creating a new ImageIcon? Why does icon2Image have to change?

[jrojcek] For each badge (or colors) explanatory line (or more lines if needed) should be added to Node description text
(which is shown as tool tip).

[JG02] Utilities.loadImage() was changed to create subclass of BufferedImage which contains tool tip String and also
implements Icon (idea of jst). Then the conversion between Image and Icon can be just casting. E.g. before change
VisualizerNode loaded Image and then created ImageIcon so each VisualizerNode had its own Icon instance - now if
VisualizerNodes use same image as an icon they share the same instance (this change is also part of posted diff). So,
its just positive side-effect.

Created attachment 62597 [details]
[JG01] Example of usage

Okay, for now I would just expect the appearance would look okay for both, the badge and color explanation. It would be nice if there was at least a mini UI 
spec written for it so that everybody can _see_ that's what we want to achieve.

This is just API to have the possibility to add the tool tip to badge icon in simple way. It is up to providers of
badges to decide text and format of their tool tips. Of course, some guidelines could be useful for them.

Created attachment 62807 [details]
Image methods were separated to new public ImageUtilities class

On jst suggestion I moved all image/icon methods from Utilities to new public class ImageUtilities (former IconManager)
and made those methods deprecated in Utilities. I plan to commit these changes tomorrow (if no more suggestions).

Comment to implementation:
+        if (icon instanceof Image) {
+            String toolTip = ImageUtilities.getImageToolTip((Image) icon);
should maybe be:
String toolTip = ImageUtilities.getImageToolTip(ImageUtilities.icon2Image(icon));

ImageUtilities should have private constructor.

Why "@author Jaroslav Tulach" - it should be "@author Tomáš Holý"!?

>String toolTip = ImageUtilities.getImageToolTip(ImageUtilities.icon2Image(icon));
If icon is not Image there cannot be tool tip so I think this would be unnecessary conversion.

>ImageUtilities should have private constructor.
ok, added.

>Why "@author Jaroslav Tulach" - it should be "@author Tomáš Holý"!?
It is in fact extended IconManager (with more appropriate name) so I preserved original author, but ok I will add myself

Diffs for review should use Git syntax (--git or [diff] git=1) to show renames correctly. I would hope that
IconManager.java was 'hg rename'd to ImageUtilities.java so that e.g. 'hg annotate' will work on old code; same for the
unit tests.


Use e.g. "{@link ImageUtilities#mergeImages}" in Javadoc.

Created attachment 62818 [details]
diff with changes (git syntax)

http://hg.netbeans.org/core-main/rev/0ba3a2a6c3c3

[AB01] This change is likely to add several hundred deprecation warnings to the build. Please fix at least the modules
in main to use ImageUtilities instead of Utilities.

There is > 900 files to change. I suggest to remove deprecation in Utilities.

Or fix existing usages in bulk using Jackpot:

org.openide.util.Utilities.loadImage($args$) => org.openide.util.ImageUtilities.loadImage($args$);
org.openide.util.Utilities.icon2Image($args$) => org.openide.util.ImageUtilities.icon2Image($args$);
org.openide.util.Utilities.mergeImages($args$) => org.openide.util.ImageUtilities.mergeImages($args$);

Currently it seems this refactoring mostly works but fails to import ImageUtilities (and clean up any unused import of
Utilities), which is probably a bug in Jackpot.

BTW current statistics on usages and the number of files and modules affected:

main$ (for r in . contrib; do hg -R $r loc -r tip -0 '**.java'; done) | xargs -0 egrep
'Utilities\.(loadImage|icon2Image|mergeImages)' | wc -l
2597
main$ (for r in . contrib; do hg -R $r loc -r tip -0 '**.java'; done) | xargs -0 egrep -l
'Utilities\.(loadImage|icon2Image|mergeImages)' | wc -l
1316
main$ (for r in . contrib; do hg -R $r loc -r tip -0 '**.java'; done) | xargs -0 egrep -l
'Utilities\.(loadImage|icon2Image|mergeImages)' | perl -pi -e 's!^(contrib/)?([^/]+)/.+!\1\2!g' | uniq | wc -l
366

Quite a job to fix up all those. Probably impractical without a script of some kind.

I tried some automatic replacement tool and replacement of method name was the simplest task. Problem was with imports
and module dependency version. If Jackpot fails to do that I would suggest to remove deprecations for now and leave
there just message to use new version in ImageUtilities.

Also typical usage of loadImage() is: "new ImageIcon(Utilities.loadImage(...));" which should be replaced by
"ImageUtilities.image2Icon(ImageUtilities.loadImage(...))" to avoid conversions to new instances.

Integrated into 'main-golden', available in NB_Trunk_Production #271 build
Changeset: http://hg.netbeans.org/main/rev/e4e7a594d0de
User: Martin Krauskopf <mkrauskopf@netbeans.org>
Log: Migrating to new ImageUtilities APIs (see issue #123469 for details)

API in 6.5m1 and UI in 6.5m2.

Thanks to all involved.

Just a suggestion, though not that important yet it makes sense. The tooltip in somecases shows-
 |> Contains main class

Why not main method? Just curious to know! It should be either of the following

 |> This is main class

OR

 |> Contains main method

nvarun, report new bug to provider of the text (probably java). Thank you

*** Issue 126019 has been marked as a duplicate of this issue. ***