I cannot reproduce it on Windows and Linux (old FC4) so likely MacOSX-specific.

CC-ing Tim. He send me the e-mail with the following info (just for the record):

It looks like handleOpenFile() is wrong - the best it could do now would be to cause a file chooser to open.
A quick look at the code for handleOpenFile() shows it to be wrong - it would just open a file chooser if it did 
anything at all.

Anyway, here's what handleOpenFile() should probably look like - I haven't tested it though.

Things to check and tune:
 - can ApplicationEvent.getFilename() ever return a list of files?
 - does handleOpenApplication() perform the same role as handleOpenFile() if no copy of NB was running?  If so, needs 
to be handled, including making sure it is not really run until all modules are loaded

Anyway, the attached patch should give it at least a shot at working.  However, I see:

But if we ever want NB to be on the Open With menu, that's going to be a bit of a challenge - see:
http://developer.apple.com/documentation/Java/Reference/1.5.0/appledoc/api/com/apple/eawt/ApplicationListener.html
"These events are sent only if the bound application has file types listed in the Info.plist entries Document Types or 
CFBundleDocumentTypes."

I suspect the event may still be sent if you choose Open With -> Other -> NetBeans.

To do this semi-right, the build process that creates the NB application bundle would need to run some sort of custom 
Ant task that finds all file extensions that the copy of NetBeans it is bundling can read, and generate the Info.plist 
that lists those file types in the metadata that describes NB to Mac OS.

Doable, but won't help for any newly downloaded modules - you need to be superuser to edit the Info.plist of an 
installed application.

Of course, hard-coding a set of file types we know we want to accept would be a start. 

Created attachment 63948 [details]
patch proposed by Tim

Caveat:  whether in handleOpenFile() or in handleOpenApplication() (reading the docs further, probably handleOpenFile() is what will be called) when a user 
double clicks a file in Finder and chooses Open With -> ...NetBeans, the documentation mentions that the event will be sent "after AWT is initialized".  That 
will be way too early in the startup sequence for the applemenu module to have registered its handler.

So my guess is, doing this without an already-running copy of NetBeans probably means adding the ApplicationListener much earlier in startup and trying to 
open the file after the main window is initialized.

Also apropos:
http://lists.apple.com/archives/java-dev/2003/oct/msg00482.html

Tim how can I test the fix? 'Open with' action on MacOSX only allows to select Something.app and I don't know how to create such launcher from sources. Is 
it even possible to debug something launched via .app launcher?

> I don't know how to create such launcher from sources

I'm not sure what you mean - could you clarify?

In case I was being unclear:  Basically, any Mac OS X application directory contains a file Contents/Info.plist

That file can contain a static list of file types the application can open.  

Right now NetBeans' Info.plist does not contain any data about file types it handles, so NetBeans only appears on the Open With menu.

To put it on the Open menu, we would want to generate a list of file types NB handles when the Mac application bundle is generated.

Does that help?

> I'm not sure what you mean - could you clarify?

I mean that if I invoke Open With I can only select application, but IDE built from sources (with the fix) is not MacOSX application, so I cannot test it.

I assume that the file Info.plist needs to be generated during IDE installation by installer.

Run the Ant script in installer/mac to build the mac application structure (I see there is installer/mac/newbuild - not sure what that is, maybe the thing that 
does the new mpkg installers?)

Both ant scripts in installer/mac (not used at the moment, not up-to-date) and installer/mac/newbuild will build the 
installers (wrapped in .dmg), neither will build the .app structure.
The Info.plist that is used now (need some token replacement), is located at installer/mac/newbuild/netBeans.

I have added the following snippet to the Info.plist file inside the netbeans.app.

	<key>CFBundleDocumentTypes</key>
	<array>
		<dict>
			<key>CFBundleTypeName</key>
			<string>com.sun.java-source</string>
			<key>CFBundleTypeRole</key>
			<string>Editor</string>
			<key>LSItemContentTypes</key>
			<array>
				<string>com.sun.java-source</string>
			</array>
		</dict>
	</array>

After some moving around of the netbeans.app (probably for apple to recognize the change), I was able to select netbeans
as the editor for a java file in the finder.
HOWEVER the our listener's ApplicationListener.handleOpenFile (ApplicationEvent e) was never called by the environment.
I've tried moving the listener registration to ModuleInstall.validate() which is the most early point in startup a
module can execute it's code. I got the ApplicationListener.handleOpenApplication (ApplicationEvent e) method called
(thus the listener is correctly registered) but the handleOpenFile() method was never called.

-> I might have done something wrong, but the finder environment behaves as if it's setup correctly.

See for description of CFBundleDocumentTypes element in Info.plist
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-101685

See for a list of default content types
http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/utilist/chapter_4_section_1.html#//apple_ref/doc/uid/TP40001319-CH205-CHDIJFGJ


Reassigning to installer, as we need the entries in the Info.plist first as a prerequisite to fix the (possible) bug in
our code that opens the file badly. Right now (without the Info.plist content) our code is not called at all.

I'm running the latest 1.5.0_16 java.

Created attachment 70888 [details]
my changes to the applemenu module

I`ve made the changed in installer to pick-up "public.shell-script" type (.sh and .command files).
http://hg.netbeans.org/main/rev/3aa6e1e3686c
(please let me know it is not enough)
.sh files editing support is included in the ideX cluster and therefore is available in every NetBeans distro.

I thought of com.sun.java-sources - but it will not work in non-Java distros and who knows what bugs it could introduce.

Passing back to core.

PS. As the long term solution we should dynamically add different CFBundleTypeName keys depending on the packs selected 
in installer. To do that we should have the full list of file extensions that we want to register and which module 
(better - cluster) is the editor support for that file type located at.

Integrated into 'main-golden', will be available in build *200810010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3aa6e1e3686c
User: Dmitry Lipin <dlipin@netbeans.org>
Log: Temporary workaround for #138943 : register .sh files for the .app

> but the handleOpenFile() method was never called

Probably the best place to ask about this is on java-dev@lists.apple.com - or I can put you in touch with someone from Apple.

dlipin: with your changes, the sh files have netbeans in the preferred list for opening. That's good. However I'm not
sure we should be shipping with the change in 6.5, especially if the file opening doesn't actually work and is only
setup for sh files.

I've asked on java-dev@apple about the problem. 
http://lists.apple.com/archives/Java-dev/2008/Oct/msg00059.html

according to this message
http://lists.apple.com/archives/Java-dev/2008/Oct/msg00077.html
the fact that we are using a shell script to start netbeans prohibits us from opening the file from finder. The shell
script blocks the OS from calling the java event callback.

closing as wontfix. 

Another user request for this feature:
http://forums.netbeans.org/topic17804.html

*** Bug 187438 has been marked as a duplicate of this bug. ***

Is this still not possible?

I agree, it's kind of odd that you can't open a simple file from the Finder and have NetBeans open it? Every other IDE/Text-Editor on the planet has this simple functionality. With NetBeans, you are forced to either use File->Open or Drag'n'Drop the file.

Can someone devise a simple work-around, such as writing a temporary file that you look for at startup? Something like "HeyNetBeans-OnceYouHaveLoadedThenOpenFileXXX"   The startup sh script could generate that file based on what the Finder wishes to open, assuming it's true that the launched IDE can't get at this information from the OS.

Another year gone by - is netbeans still technically unable to open files from Finder?

Another year gone by - is netbeans still technically unable to open files from Finder?

Anyone working on this?

*** Bug 191708 has been marked as a duplicate of this bug. ***

IFAIK the current launcher for Mac doesn't allow to make this association. Any patch/hints are welcome.

Just adding another comment that some solution to this would be very much appreciated.

This bug has been reported almost 5 years ago, and AFAIK there is still no solution.
I think this is a basic functionality for an IDE/editor.
I gave up. Moved to another IDE for Mac OS. Sorry for my useless comment.

This AppleScript do the job :

https://github.com/bunam/NetBeans-Open

*** Bug 246941 has been marked as a duplicate of this bug. ***

*** Bug 248009 has been marked as a duplicate of this bug. ***

Having the same issue in my new Mac OS X Yosemite 10.10.4 and Netbeans version 8.0.2

This still does not work on OS X Yosemite 10.10.5 and Netbeans 8.0.2. Do the developers have any plans to fix this in Netbeans 8.1 or a future version?

This still does not work on OS X Yosemite 10.10.5 and Netbeans 8.1

This still does not work on MacOS Sierra and Netbeans 8.2