Community
Participate
Working Groups
Eclipse version = I20070208-1200 Steps To Reproduce: (1) Launch a host instance of eclipse (2) Create a new plug-in project using the hello world template -> Plug-in manifest editor opens on the "Overview" page (3) Switch to the "Extensions" page -> Problem: Notice that the tree widget does not have any painted borders (4) Create a default eclipse application launch configuration (5) Run the launch configuration (6) In the target instance, create a new plug-in project using the hello world template -> Plug-in manifest editor opens on the "Overview" page (7) In the target instance, switch to the "Extensions" page -> Notice that the tree widget has a border now (8) Shutdown the host and target instance of eclipse (9) Launch a host instance of eclipse using the following command: eclipse -vmargs -XstartOnFirstThread -> Re-use the previous workspace used to launch the first host instance of eclipse (or create a new plug-in project as before) (10) Switch to the "Extensions" page -> Notice that the tree widget has a border now The -XstartOnFirstThread VM argument is required to launch eclipse on the Mac Please see: http://www.eclipse.org/swt/faq.php#carbonapp
In a nutshell, if you double-click on the exe to launch Eclipse on Mac, no borders will appear (e.g. see the Extensions table on the Extensions page of the manifest editor). If you launch eclipse and pass in -XstartOnFirstThread, borders appear fine. What is the deal here? Is that startOnFirstThread arg still required with the new launcher? If so, was it accidentally left out of some ini file in the packaged Mac drop?
I believe that the -XstartOnFirstThread is present in the Info.plist, but not in the eclipse.ini. So therefore when you double-click the app, the -XstartOnFirstThread is added; but if you run the executable manually (or the PDE processes the eclipse.ini) then it isn't. I think you need it in the Info.plist too; the question is, is it dangerous to have it in two places? What's the effect of having java -XstartOnFirstThread -XstartOnFirstThread?
My mistake. It's not in the Info.plist; it's just in the eclipse.ini However, when you're re-running it the second time (with the border) you're missing out: -Dorg.eclipse.swt.internal.carbon.noFocusRing which disables the focus ring. Although it's present on eclipse installs, it's generally not used on Macs, which is why that's the default IIRC.
Alex has found the difference: the presence or absence of the noFocusRing property. The ini and plist files appear to be read properly by the launcher. VM arguments on the command line override the ini file, so by specifying -vmargs -XstartOnFirstThread on the command line, the result will be that there is no -Dorg.eclipse.swt.internal.carbon.noFocusRing property. Similarily, the self hosted eclipse does not appear to have this property set either. I'm not clear on which is the desired behaviour, do we want to remove the noFocusRing property from the ini file, or do we need to add it to the self hosted eclipse?
Andrew, let's not worry about the self-hosted Eclipse. It is working fine as we bypass the exe altogether. What we want is people to launch Eclipse using the exe and see borders on tables on Mac. So let's do what we have to do.
I looked at 3.2 and 3.2.1, both have this same behaviour. We can change the ini file to remove the noFocusRing if desired, but I don't think this is critical and I don't think we need to respin M5 for it. A quick look at the history shows it has been there from at least the beginning of 3.2. Was it put there for any particular reason?
The org.eclipse.swt.internal.carbon.noFocusRing property was added as a temporary fix for bug#28842. We have decided it is time to get ride of it. You can stop setting it in the INI file. Tables in the MANIFEST.MF forms should have borders from now on.
Good to know, thanks.
done in HEAD
Changing OS from Mac OS to Mac OS X as per bug 185991
*** Bug 151529 has been marked as a duplicate of this bug. ***
