Community
Participate
Working Groups
The 'nice' OS X icon for Eclipse is in Eclipse.app/Contents/Resources/Eclipse.icns, and is the one shown in finder. When launching Eclipse 3.3M5, the 'nice' icon is set. However, during startup, the product configurator gets called, which then subsequently does an SWT setImage on the Display/Shell, which has 'nasty' icons (plugins/org.eclipse.sdk.../eclipse32.gif) In 3.3M4, if a dock icon was specified, then the setImages on the display/shell had no effect. However, now it appears to take precedence over whatever the dock icon is. It wouldn't be so bad if the icon was the nice one (see also additional bug in PDE/UI re: Mac icon looking different on PDE launches; however this same problem affects the host Eclipse too) Mac OS X 10.4.8, Eclipse 3.3M5. An oddity; I'm running PPC but the configuration runs with -arch x86. However, osgi.processor=ppc in the environment settings.
Created attachment 58722 [details] Whilst 3.3M5 is launching (bottom Eclipse icon) Note that the icon mid-way up is Eclipse 3.3M4 and the one at the bottom is Eclipse 3.3M5 during launch
Created attachment 58723 [details] Launch afterwards - note lower Eclipse icon changed to nasty Once the dialog is up and the Display/Shell setImages has been called, the icon goes from nice to nasty. Lower icon now clearly different from icon mid-point up.
If someone sets the icon to a nasty one, we still need to draw it. Am I missing something or this this a WONTFIX for SWT?
*** This bug has been marked as a duplicate of bug 170216 ***
This isn't a duplicate of 170216; it's a regression/change of behaviour. 170216 has icons in the plugin that are set with setImage on the display, and the icons are the wrong ones. In 3.3M4 and below, if the dock icon was set with -Xdock:icon then the call to setImage had no effect; in other words, it only set the dock icon if the dock icon wasn't already set. Now, the behaviour is different; the setImage overrides the icon in the dock. In both cases the setImage was being called; in 3.3M5 the setImage is obliterating whatever icon may have been on the dock initially. Other people who bundle an app may well be confused by this behaviour; if an icon has been set on the -Xdock:icon, then it shouldn't be overwritten in the setImages call.
No change was made to SWT in this area. The -Xdock:icon option is not overriding by Shell.setImage()/setImages(). I believe that the problem is happening because the eclipse executable does not exec java anymore, so the option -Xdock:icon is not converted into a system environment variable called APP_ICON_<pid>. Note that it works fine if you set the option (through VM args in run configuration dialog) and self-host. That is because "java" is used when self-hosting, not the eclipse executable.
The launcher is now setting the APP_ICON_<pid> and APP_NAME_<pid> environment variables. The nice icon is staying.
Changing OS from Mac OS to Mac OS X as per bug 185991
