Community
Participate
Working Groups
Bugzilla – Bug 204582
Mac - manually added external editors fail to launch
Last modified: 2009-10-26 12:29:14 EDT
To reproduce, on Mac version of Eclipse: Go to Eclipse --> Preferences --> General --> Editors --> File Associations "Add" a content type in upper right for a file format not on the list (i.e. *.fla for Flash files) Note that file icon is added to list but is generic "page" icon Then add the Flash application using the "Add" button in the bottom right --> point to the app on your HD Then from the explorer window, try and launch the external editor by right clicking on a FLA file and selecting "Open With --> Other" The exernal editor will not open and Eclipse will offer up a mysterious dialog box saying that the editor failed to launch. I tried with other programs (i.e. CSS Edit for *.css files --> same behaviour) This works fine on the PC version of the program.
Moving to SWT since platform specific.
I'm able to reproducible the error using CSSEdit. This happens on Carbon but NOT on Cocoa. When user selects Open with -> other... , a list of available programs is populated in the Editor Selection dialog. CSSEdit is not listed here because Program.getPrograms() gets the programs only for the extensions returned by Program.getExtensions(). And *.css, *.fla are not listed in the getExtensions() in Carbon. These extensions are actually not in the apple System-Declared Uniform Type Identifiers. In Cocoa, we use a different way to get the programs and hence we don't have this problem there. Now, since CSSEdit is not listed, the user uses Browse in the Editor selection dialog to select the CSSEdit.app. The user gets an error, because the code to open the ExternalEditor tries to execute(exec) CSSEdit.app. I'm not sure if I should fix this by adding the missing extensions in the Program.getExtensions() or reassign to platform-inbox. Carolyn, can you please suggest what I should about this bug.
It is ok to add extensions to the list in Program.getExtensions(). When you add ".css", does CSSEdit.app open correctly, or is there still an error? If there is still an error, then you will need to also open a bug against platform-ui. One other interesting possibility is to copy the code from Cocoa Program.getExtensions(). It should hopefully be straightforward to get that code working in Carbon, mostly by changing all NS... calls to their OS.CF... equivalent. You will have to use Cocoa.objc_msgSend() for NSWorkspace.isFilePackageAtPath() because it is only in Cocoa. This is probably a better fix, because then the problem won't come up again with some other file extension.
> When you add ".css", does CSSEdit.app open correctly, Yes, adding the missing extension fixes both the problems. -- When the application is added in the file associations dialog, the applications icons is shown and not the generic "page" icon. -- The application opens the file without any errors. I'm trying the other approach -- making the Carbon code similar to the Cocoa code so that we'll not have this problem with some other file extension.
Created attachment 146489 [details] patch for carbon The getExtensions() in the patch gets the extensions in the same way as Cocoa does. It gets all the extensions which Cocoa Program.getExtensions() gets. Used HashSet to avoid duplicate extensions. The patch fixes the two problems as mentioned in comment #5. 1) Adding a file associaton -- Go to Eclipse --> Preferences --> General --> Editors --> File Associations Clicking on "Add" Editor, opens the Editor Selection dialog. All applications from the Application folders (/Applications, /Users/username/Applications, /Developer/Applications, ..) are listed here. Select any of the applications from here and add it. The application's icon is shown and not the generic page icon. 2) Opening a file with a different application -- right click --> Select Open With --> Other... on the file to be opened, Editor Selection dialog opens. All the applications are listed here. Select the appropriate application from this list and the file opens without any error. Tested with CSSEdit and opens fine now. Carolyn, please review the patch.
The patch fixes this bug by listing all the applications in the "Editor Selection dialog" and the user can select the appropriate application to open. But, if we use the Browse in the "Editor Selection" dialog to browse to the same application we still get an error. Opened a bug with platform UI for this https://bugs.eclipse.org/bugs/show_bug.cgi?id=288624
I believe this line: int string = Cocoa.objc_msgSend (array, Cocoa.S_objectAtIndex, i); can be replaced by: int string = OS.CFArrayGetValueAtIndex(array, j); since NSArray and CFArrayRef are toll-free. We have been avoiding java collections, because there were introduced in Java 1.2. CFSetCreateMutable() and CFSetAddValue() could be used instead.
Created attachment 146913 [details] patch Thanks for the comments, Silenio. I have modified the patch so that it doesn't use HashSet now. I tried to use the CFMutableSet created using CFCreateMutableSet(). After adding all the values the Set had many duplicate strings. It by default compares the reference values and not String values. Hence, used cocoa call to create an empty NSMutableSet and used it in place of CFMutableSet in the other calls. Please review the modified patch.
You need to pass kCFTypeSetCallBacks as the callbacks parameter of CFSetCreateMutable() to avoid the duplicates. int supportedDocumentTypes = OS.CFSetCreateMutable(OS.kCFAllocatorDefault, 0, OS.kCFTypeSetCallBacks());
Created attachment 146997 [details] patch Modified the patch to pass the callback to the CFCreateMutableSet. Thanks Silenio!
Fixed > 20091001. Released the patch with a couple of alterations: 1) supportedDocumentTypes has to be released (leak). The "leaks" command line tool is useful to detect these problems. 2) the folderUrl array is not needed. Changed a few variable names as well.