Community
Participate
Working Groups
When starting without the native launcher and with -ws, we guess a default ws based on the OS. For the mac, the default is carbon. Should we consider changing this to cocoa? I guess this may depend on the download stats for the two platforms. See for example the log attached to bug 285513, this was irrelevant there, but if we had been trying to run an app that wasn't headless it would have failed. There are two places to make this change, EclipseEnvironmentInfo#guessWS and Main#getWS
I think guessing cocoa makes sense going forward. We're concentrating our efforts on cocoa more so than carbon for 3.6 and beyond. *Carbon still needs to work though.
This is similar to bug 185952 when we switched from motif to GTK. We should do this early in 3.6. Note that we will have automated testcases to update as well.
Created attachment 143786 [details] fix + test Here is the fix and updated test.
We discussed this at the architecture call. The following concerns were raised: 1) Any time we change the default behavior there are concerns about backwards compatibility. Is it worth the change? Is it really that important to change the default here? 2) Is there a better way to guess? Could we look to see what native codes are installed and guess based on that (e.g. the SWT fragment for cocoa is present). This is not likely to be straight forward because we have not even gotten to p2 yet to install the SWT fragments before we need to guess. 3) Should we mandate that -ws or osgi.ws is set in the launcher instead and print some message if it is not specified? Perhaps exit? Although I think exiting would pose a greater concern about backwards compatibility (think headless apps that don't care about the ws).
-1 for option 3) this is more breaking than just switching the default. Better guessing e.g. based on what's installed sounds tempting. If this doesn't work out then I'd switch the default to Cocoa given that's what Apple suggests to use for new apps.
The Main class will look for the launcher fragment, one strategy for a better guess is if we fail to find the default, we can look for the other one. Finding the non default could have Main pass the corresponding -ws to the framework.
(In reply to comment #6) > The Main class will look for the launcher fragment, one strategy for a better > guess is if we fail to find the default, we can look for the other one. > Finding the non default could have Main pass the corresponding -ws to the > framework. > Ah, I forgot the launcher did the search for a launcher fragment. I think this may be a feasible solution.
(In reply to comment #6) > The Main class will look for the launcher fragment, one strategy for a better > guess is if we fail to find the default, we can look for the other one. > Finding the non default could have Main pass the corresponding -ws to the > framework. > This would involve defining the alternate ws, which is rather straightforward: gtk <-> motif carbon <-> cocoa (or cocoa->carbon) win32 <-> wpf (? perhaps unnecessary)
I raised bug 286453 and attached a patch there for trying an alternate ws when the default is not found. Independently, we can either change the mac default to cocoa, or close this as won't fix.
I don't think we should change the default at this point. The fix in bug 286453 should provide the behavior we want.
