Community
Participate
Working Groups
Created attachment 242982 [details] screen shot Version: Luna (4.4) Build id: I20140511-2000 See the attached screen shot - the dock icon for a target workspace is blurry.
The application launches appear to be the same. However, it may be related to some mac specific code in the EclipseApplciationLaunchConfiguration if (!programArgs.contains("-nosplash") && showSplash) { //$NON-NLS-1$ if (TargetPlatformHelper.getTargetVersion() >= 3.1) { programArgs.add(0, "-launcher"); //$NON-NLS-1$ IPath path = null; if (TargetPlatform.getOS().equals("macosx")) { //$NON-NLS-1$ path = new Path(TargetPlatform.getLocation()).append("Eclipse.app/Contents/MacOS/eclipse"); //$NON-NLS-1$ } else { path = new Path(TargetPlatform.getLocation()).append("eclipse"); //$NON-NLS-1$ if (TargetPlatform.getOS().equals("win32")) { //$NON-NLS-1$ path = path.addFileExtension("exe"); //$NON-NLS-1$ } }
Works for me in 4.4.0.I20140513-2000. Both the host and the runtime Eclipse have the same sharp icon in the Dock and in Command+Tab. Maybe your workspace contains some outdated projects that missed the latest icon updates?
(In reply to Markus Keller from comment #2) > Works for me in 4.4.0.I20140513-2000. Both the host and the runtime Eclipse > have the same sharp icon in the Dock and in Command+Tab. > > Maybe your workspace contains some outdated projects that missed the latest > icon updates? Can you test a JUnit Plug-in Test launch? I never updated the bug, but when I checked the issue on Mike's machine it only occurred for JUnit launches.
> Can you test a JUnit Plug-in Test launch? Yup, reproduced with a PDE JUnit launch. And adding these command-line arguments also didn't help: -Xdock:icon=/Volumes/Eclipse/4.4-I-builds-x86_64/Eclipse.app/Contents/MacOS/../Resources/Eclipse.icns -launcher /Volumes/Eclipse/4.4-I-builds-x86_64/Eclipse.app/Contents/MacOS/eclipse I guess the problem is that the org.eclipse.pde.junit.runtime.uitestapplication doesn't use the -launcher. In this situation, the fallback uses the windowImages specified in /org.eclipse.sdk/plugin.xml, but these end at eclipse48.png now (bug 432741). Adding e.g. eclipse512.png there fixes the problem. (The icons are eventually set via Decorations#setImages(..)).
(In reply to Markus Keller from comment #4) > > Can you test a JUnit Plug-in Test launch? > > Yup, reproduced with a PDE JUnit launch. And adding these command-line > arguments also didn't help: > > -Xdock:icon=/Volumes/Eclipse/4.4-I-builds-x86_64/Eclipse.app/Contents/MacOS/. > ./Resources/Eclipse.icns > -launcher > /Volumes/Eclipse/4.4-I-builds-x86_64/Eclipse.app/Contents/MacOS/eclipse > > > I guess the problem is that the > org.eclipse.pde.junit.runtime.uitestapplication doesn't use the -launcher. > > In this situation, the fallback uses the windowImages specified in > /org.eclipse.sdk/plugin.xml, but these end at eclipse48.png now (bug > 432741). Adding e.g. eclipse512.png there fixes the problem. > > (The icons are eventually set via Decorations#setImages(..)). Is there no way for the Eclipse code to use the icns file? It would be better, if it did, not only for this specific case, but because it contains the "double resolution" images for retina displays too ... so long term, ... that would be a superior solution for Mac users.
(In reply to David Williams from comment #5) > > > > I guess the problem is that the > > org.eclipse.pde.junit.runtime.uitestapplication doesn't use the -launcher. > > > > In this situation, the fallback uses the windowImages specified in > > /org.eclipse.sdk/plugin.xml, but these end at eclipse48.png now (bug > > 432741). Adding e.g. eclipse512.png there fixes the problem. > > > > (The icons are eventually set via Decorations#setImages(..)). > > Is there no way for the Eclipse code to use the icns file? It would be > better, if it did, not only for this specific case, but because it contains > the "double resolution" images for retina displays too ... so long term, ... > that would be a superior solution for Mac users. I should also mention, if this is a case you know exactly what image/png file you want ... it is still there, in the eclipse sdk plugin, if there was a way to refer to it specifically ... I hesitate to fix by adding to "windowImages" since a) that would lose the fix for bug 432741. b) I'm still not sure it would work for "EPP packages" since they only specify 3 images, not the 512 one, in their list of "windowImages".
OK, I think I understand the problem: It's not about the launcher executable / Info.plist at all. That one only matters if you launch the Eclipse.app. It's all about having this in the *VM* args (comment 4 had it as program args): -Xdock:icon=/<full-path-to>/Eclipse.app/Contents/Resources/Eclipse.icns New "Eclipse Application" and "JUnit Plug-in Test" launch configurations automagically get the VM arg -Xdock:icon=../Resources/Eclipse.icns For "Eclipse Application", the relative path works because the default working directory is /<full-path-to>/Eclipse.app/Contents/MacOS. But for "JUnit Plug-in Test", the default working directory is ${workspace_loc:<project-name>}, which breaks the relative path above. It works if the VM arg is -Xdock:icon=${eclipse_home}Eclipse.app/Contents/Resources/Eclipse.icns Now, the trouble is that the default -Xdock:icon=../Resources/Eclipse.icns seems to come from the sdk.product file, so it's not something PDE UI should overwrite. The relative path can only work if the working dir is the default, but PDE JUnit launch configs traditionally have the test project as default $PWD. Also not something that should be changed. Maybe this could be fixed with an ugly hack somewhere around org.eclipse.pde.launching.JUnitLaunchConfigurationDelegate#collectExecutionArguments(..) that replaces '-Xdock:icon=..' with the "Eclipse Application"'s default working directory.
(In reply to Markus Keller from comment #7) > OK, I think I understand the problem: It's not about the launcher executable > / Info.plist at all. That one only matters if you launch the Eclipse.app. > > It's all about having this in the *VM* args (comment 4 had it as program > args): > > -Xdock:icon=/<full-path-to>/Eclipse.app/Contents/Resources/Eclipse.icns > > > New "Eclipse Application" and "JUnit Plug-in Test" launch configurations > automagically get the VM arg -Xdock:icon=../Resources/Eclipse.icns > > For "Eclipse Application", the relative path works because the default > working directory is /<full-path-to>/Eclipse.app/Contents/MacOS. > > But for "JUnit Plug-in Test", the default working directory is > ${workspace_loc:<project-name>}, which breaks the relative path above. It > works if the VM arg is > -Xdock:icon=${eclipse_home}Eclipse.app/Contents/Resources/Eclipse.icns > > > Now, the trouble is that the default -Xdock:icon=../Resources/Eclipse.icns > seems to come from the sdk.product file, so it's not something PDE UI should > overwrite. The relative path can only work if the working dir is the > default, but PDE JUnit launch configs traditionally have the test project as > default $PWD. Also not something that should be changed. > > Maybe this could be fixed with an ugly hack somewhere around > org.eclipse.pde.launching. > JUnitLaunchConfigurationDelegate#collectExecutionArguments(..) that replaces > '-Xdock:icon=..' with the "Eclipse Application"'s default working directory. Would a slightly less ugly hack be for the launcher to copy the Eclipse.icns file to ${workspace_loc:<project-name>} (or whatever "working location" is)? I will admit, though, I would have thought there'd be an API to "getImageResourceFromExecutable" ... for example, if someone is using Luna to develop a "Kepler App" (with Kepler product in runtime target) it seems better to display the "Kepler Icon" for this scenario? [Apologies in advance if my comments are over simplistic, since I know nothing about this area :/ ]
(In reply to David Williams from comment #8) > Would a slightly less ugly hack be for the launcher to copy the Eclipse.icns > file to ${workspace_loc:<project-name>} (or whatever "working location" is)? That would be ugly because you then get outgoing changes on the test projects. Moving back to PDE to consider comment 7.
(In reply to David Williams from comment #8) > I will admit, though, I would have thought there'd be an API to > "getImageResourceFromExecutable" ... for example, if someone is using Luna > to develop a "Kepler App" (with Kepler product in runtime target) it seems > better to display the "Kepler Icon" for this scenario? There is already such an API -- sort of... It's the combination of the working directory and the -Xdock:icon argument. If they are set correctly, then everything is fine. But for PDE launch configs, there's usually no "correct" combination, since they don't launch an OS app, but they launch a Java VM. We can compensate for that by tweaking the -Xdock:icon argument. As you've correctly said, such a compensation will fall short if the target is not the same product as the host (the usual case outside of Eclipse platform development). Or we make the fallback good enough (windowImages, which is actually the primary mechanism on Windows and GTK).
Created attachment 243260 [details] Hack from comment 7 Here's the hack from comment 7 that checks if the -Xdock:icon argument resolves to an icon file. If there's no file there, then it tries to use the working directory of the host workbench as the basis for the -Xdock:icon argument. However, I don't think this is the right solution, because it will only look correct for Eclipse platform developers. I would not release this, but make the windowImages list in the product complete again and then have the SWT implementation of Decorations#setImages(..) fix the problems you were seeing with "emblems" on Linux.
(In reply to Markus Keller from comment #11) > Created attachment 243260 [details] > Hack from comment 7 > > Here's the hack from comment 7 that checks if the -Xdock:icon argument > resolves to an icon file. If there's no file there, then it tries to use the > working directory of the host workbench as the basis for the -Xdock:icon > argument. > > However, I don't think this is the right solution, because it will only look > correct for Eclipse platform developers. > > I would not release this, but make the windowImages list in the product > complete again and then have the SWT implementation of > Decorations#setImages(..) fix the problems you were seeing with "emblems" on > Linux. I opened bug 435222 but would like to hear what they have to say before making any decision. I assume you realize that us adding back the higher res image won't help EPP packages (by far the greatest downloads at Eclipse) ... and even if we convinced them to add 4 images to their list to get a sharper image for this use-case, then all Linux users would lose the "emblem", so would be a bad regression for them. So, as I say in bug 435222 ... we may have a tough choice ... blurry image, or regression for all Linux users (who use EPP packages).
If you have time/ability, can someone try this scenerio starting with binary Eclipse platform? (and "build it up" from repo to contain jdt and pde). I ask because I just noticed in the Mac's "SDK product definition" it had an empty "windowImages list" (literally <windowImages/>) in addition to the later having <macosx icon="icons/Eclipse.icns"/>, etc. It probably makes no difference what's so ever ... but ... doesn't seem right to have an empty <windowsImages/> element ... or else both should. I was just wondering if it made any observable difference in behavior, or just "ignored junk" in the product definition file. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/sdk/sdk.product#n15
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. -- The automated Eclipse Genie.
