Bug 204582 - Mac - manually added external editors fail to launch
Mac - manually added external editors fail to launch
Status: RESOLVED FIXED
Product: Platform
Classification: Eclipse
Component: SWT
3.4
Macintosh Mac OS X - Carbon (unsup.)
: P3 major (vote)
: 3.6 M3
Assigned To: Lakshmi Shanmugam CLA Friend
Carolyn MacLeod CLA Friend
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-09-25 13:12 EDT by Barnaby Marshall CLA Friend
Modified: 2009-10-26 12:29 EDT (History)
5 users (show)

See Also:


Attachments
patch for carbon (8.11 KB, patch)
2009-09-04 07:06 EDT, Lakshmi Shanmugam CLA Friend
no flags Details | Diff
patch (10.02 KB, patch)
2009-09-10 17:25 EDT, Lakshmi Shanmugam CLA Friend
no flags Details | Diff
patch (9.58 KB, patch)
2009-09-11 16:15 EDT, Lakshmi Shanmugam CLA Friend
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Barnaby Marshall CLA Friend 2007-09-25 13:12:28 EDT
 
Comment 1 Barnaby Marshall CLA Friend 2007-10-02 12:14:30 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.

Comment 2 Kevin McGuire CLA Friend 2007-10-03 17:47:07 EDT
Moving to SWT since platform specific.
Comment 3 Lakshmi Shanmugam CLA Friend 2009-08-11 13:52:16 EDT
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.
Comment 4 Carolyn MacLeod CLA Friend 2009-08-12 12:52:35 EDT
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.
Comment 5 Lakshmi Shanmugam CLA Friend 2009-08-27 16:04:52 EDT
> 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.
Comment 6 Lakshmi Shanmugam CLA Friend 2009-09-04 07:06:21 EDT
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.
Comment 7 Lakshmi Shanmugam CLA Friend 2009-09-04 07:30:33 EDT
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
Comment 8 Silenio Quarti CLA Friend 2009-09-08 10:57:19 EDT
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.
Comment 9 Lakshmi Shanmugam CLA Friend 2009-09-10 17:25:41 EDT
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.
Comment 10 Silenio Quarti CLA Friend 2009-09-11 09:45:21 EDT
You need to pass kCFTypeSetCallBacks as the callbacks parameter of CFSetCreateMutable() to avoid the duplicates. 

int supportedDocumentTypes = OS.CFSetCreateMutable(OS.kCFAllocatorDefault, 0, OS.kCFTypeSetCallBacks());
Comment 11 Lakshmi Shanmugam CLA Friend 2009-09-11 16:15:55 EDT
Created attachment 146997 [details]
patch

Modified the patch to pass the callback to the CFCreateMutableSet. Thanks Silenio!
Comment 12 Silenio Quarti CLA Friend 2009-10-01 17:49:08 EDT
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.