Community
Participate
Working Groups
- launch a FileDialog on OSX and select your eclipse executable, press OK - the return value is <eclipseRootDir>/eclipse.app instead of <eclipseRootDir>/eclipse I don't know if this is semantically correct on OSX, but it's a consistency problem because having the FileDialog answer a directory will cause problems for any client that's (correctly) assuming that the answer must represent a file.
FH to investigate.
I don't know what is semantically correct on OSX and what is not. Andre, can you shed some light in here ? Thank you
The problem is that from the client's perspective, the answer should always represent a file, regardless of the platform.
Yes, this is a tough problem. I don't have a solution for this, but here are some factoids/thoughts: - MacOS X applications are not necessarily represented by executable files only. An application with UI is typically represented as a "bundle", that is a folder containing a manifest and various other resources. - "Bundles" cannot be launched by a Unix-style "exec"; launching requires either use of "LaunchServices" or the application name must be passed to /usr/bin/open and there is a third way: - bundles contain a single executable file in Xxx.app/Contents/MacOS/ that can be used to launch an application with "exec", however the name of this file must be extracted from the Info.plist file (XML), that represents the manifest for the bundle. Applications lauched this way behave slightly differently than applications launched via the official way. E.g., IIRC you can launch them more than once. So I'm not sure whether this "third" way is a viable solution. - the native FileDialog can be configured to allow navigation inside bundles. SWT uses it this way. If bundle navigation is not enabled, an end user could select an application bundle (the Xxx.app directory), and it would look like a normal file. However the object returned from the native filedialog would still be a directory (which cannot be passed to "exec"). - Eclipse cannot deal with bundles at all because it assumes that an application is represented by a file that can be passed to "exec". This assumption is wrong on MacOS X. A better approach for Eclipse would be to provide a high level version of "exec" that knows how to deal with application bundles, i.e. to use /usr/bin/open to launch them. A workaround would be to make the SWT filedialog return the "real" executable contained inside the bundle (instead of the bundle directory). However, for this the filedialog would need to know upfront whether it is used to select an application.
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
Closing report, platform is discontinued. Works on cocoa.
