Community
Participate
Working Groups
When launching a PDE runtime eclipse app, the icon that comes up in the dock is different from the Eclipse that launched it. It looks like the icon was changed (e.g. about 3.1->3.2) for the dock, but the change wasn't reflected in the icon for the runtime application.
Unfortunately, I don't have a mac machine to test this out on, but if we are referencing an icon incorrectly, it should show up on all OS's. I am confused on which icon is not matching. I figured you are not talking about the splash screens. Are you talking about the icon used for the "Eclipse Application" (our runtime workbench) in the debug's Run dialog?
PDE does not control what icons to show etc. This is an IDE issue.
I should point out that this is the icon shown in the Mac OS X Dock, which is the visual representation of the application running (think the menus on the start bar in Windows or shown up when Alt+Tabbing). The Eclipse app is stored under Eclipse.app/Contents/Resources/Eclipse.icns. This is made possible by the addition of this flag on Mac systems starting the VM: -Xdock:icon=../Resources/Eclipse.icns I believe that if the app doesn't have an icon, something magic happens to set a default (which is the different one). I don't know how this process works ... Andre Weinland may have more of an idea, since he's done a lot on the Mac. However, supplying -Xdock:icon=/path/to/Eclipse.app/Contents/Resources/Eclipse.icns on the Java VM args in the PDE launch configuration would almost certainly solve the problem. Of course, there may be customisations in the .product which would show a different icon; I'm not sure what effect this would have.
According to a post by SWT Steve: http://www.eclipsezone.com/forums/thread.jspa?messageID=92126128� "SWT does not supply a default [icon]. We support -Xdock:icon. However, if you set the icon for a shell and a dock icon has not been supplied, we use that. That's probably what you are seeing. " So, because the runtime PDE is created without the -Xdock:icon argument, the icon starts off as the default 'no icon'. After the splash has gone, and when the main menu is displayed, the dock picks up on the shell's icon (which presumably therefore looks different). If PDE generated the launch config with an entry -Xdock:/path/to/Eclipse.app/Contents/Resources/Eclipse.icns, then the icon would show properly. However, this is a specific option to Apple VMs, and (e.g.) launches that had this entry in that were shared in a project with other platforms, it might prevent the launch from working. What would work is to have something like: if(System.getProperty("os.name").equals("Mac OS X)) vmargs += "-Xdock:/path/to/Eclipse.app/Contents/Resources/Eclipse.icns" in the Java launcher for Eclipse runtime workbenches, then it wouldn't affect the launch at all. But if that's the case, then it probably deserves to be transferred to JDT, doesn't it?
*** Bug 152655 has been marked as a duplicate of this bug. ***
OK, so I now know why this is happening and have some proposed solutions :-) When a Java app starts on the Mac, it uses an .icns file if launched via an executable inside an .app bundle. (That's what gives the Eclipse.app its icon, or indirectly via the Thing.app/Contents/Info.plist, which then often ends up pointing to Thing.app/Contents/Resources/Thing.icns). The 'new' Eclipse icons are in Eclipse.app/Contents/Resources/Eclipse.icns, and so that's what the main Eclipse uses. If a Java program is launched outside of an .app launch, then it uses the icon supplied on the -Xdock:icon command line arg. This is also supplied by the eclipse.ini on the Mac, which has -Xdock:icon=../Resources/Eclipse.icns; I believe that the former takes precedence, but it points to the same file anyway. NB the Eclipse runtime also has -Dorg.eclipse.swt.internal.carbon.smallFonts -Dorg.eclipse.swt.internal.carbon.noFocusRing on the Mac ini, which are not relevant to this bug but see also bug 169632 If there is no -Xdock:icon, then a blank 'Java' icon is shown (somewhat ugly). However, when an SWT Shell is created and setImage() or setImages() are called, if the dock icon hasn't been initialised then the dock icon is taken from that list, using a sort that acquires the largest icon available, preferring transparent images to non transparent images -- see Mac OS X's Decorations#setImages and #sort (http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse%20SWT/carbon/org/eclipse/swt/widgets/Decorations.java?view=markup) The net result is that the newly started instance shows the ugly Java icon briefly, then is replaced with this lookup by virtue of the Shell having setImages called. This is ultimately driven from the Product, which in the trivial testing case is the org.eclipse.sdk product (though of course, that's changeable by default to other products) e.g. plugins/org.eclipse.sdk_3.3.0/eclipse32.png appears to be being used. So, there seems to be several possible ways of fixing the solution: 1) Tack on -Xdock:icon=/path/to/Eclipse.app/Contents/Resources/Eclipse.icns onto the startup parameters on Mac OS X (note: can't be done on launch config, since that might be shared between other OSes which don't understand the -Xdock option). If doing that, also consider the other -D values above, and -Xdock:name=Eclipse as well. 2) Put in a Mac OS X 'new' icon with a bigger resolution for setting on the dock as part of the feature. Slight downside; other systems might also treat that as a special image; whilst Windows might only deal with (say) 48x48, the Mac can handle 128x128 IIRC. 3) Modify the setImages code such that a special named image (or name pattern, like *_dock.png) takes priority over anything that's there on the Mac for the dock icon, so having a *_dock.png will guarantee that gets used for the dock instead. Of course, this then needs to be installed on a product-by-product basis. IMNSHO it would be better to supply the -Xdock: thing, because you can hook that up with the PDE launch that works only on a Mac, whereas the other ones would affect features that potentially could be deployed on other systems (unless the dock icon was shipped as a fragment, of course.) But also, even if the setImages is used to correctly identify the dock icon, there's still the flash of the java box as it launches but before the setImages is called. The -Xdock: approach will set the icon's image up prior to that occuring, and also will work regardless of feature/product. (Of course, by then, PDE will know what the product to be launched is so could dynamically choose a different icon if required I guess). Alex.
Created attachment 57959 [details] Eclipse PNG 128x128 This is a 128x128 PNG with alpha that was taken from the Eclipse.icns file, and thus will look the same as the existing dock icon. If this is dropped into a product plugin, then it should take precedence over the 48x48 pngs and be used for the dock icon; but I was unable to get that to work (probably just needs suitable -clean to get the new value or run in a fresh workspace I expect)
This may be fixed by bug 166223, but the reference to the resources may not be fully qualified: -Xdock:icon=../Resources/Eclipse.icns so I'm not sure whether this will actually result in worse behaviour because of 166223; if there's no dock icon, the dock is taken from the shell; however, if there is a dock icon, it will use that. However, I doubt that the CWD is the same for the launching Eclipse vs the launching PDE, so this will have the effect of removing the icon completely. Adding Chris as CC since he fixed 166223 as well.
NB This is still a problem launching a runtime IDE from within Eclipse on 3.3 final
Changing OS from Mac OS to Mac OS X as per bug 185991
This still happensin 3.5m6 by the way
This is still an issue
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
