Bug 57364

Probably core issue, reassigning for eval.

I guess the problem here is that the IDE simply ignores the filename argument,
simply because no CLI (command-line interface) handlers handles it. The
Utilities module's CLI handler only handles pairs of arguments in one of the
following forms:

    -open <filename>
    --open <filename>

But if NetBeans is associated with certain file type, when the user tries to
invoke such a file, the system passes just one argument, the <filename>.

I can implement a partial fix in the Utilities module in that its CLI handler
will also accept single <filename> argument if it is the only non-null argument
(i.e. not yet handled by other CLI handlers).

I think it is a reasonable improvement. It is good in that maybe it might work
in most cases. The bad thing is that is is definitely not systematic and it does
not cover 100 % cases.

Yarda, what do you think?

Created attachment 21388 [details]
patch (Utilities)

Accepted (and confirmed).

I will integrate the attached patch to the trunk code base and then decide
whether to port it to "release41" or not.

I think the patch fully fixes the described problem because when an associated
application is run by a user desktop environment, it passes exactly one argument
- the file name - and that is the case fixed by the patch.

I integrated the patch into the trunk (as announced).

Modified file:

    utilities/clisrc/org/netbeans/modules/openfile/cli/Handler.java   (1.5)

Diff:
http://utilities.netbeans.org/source/browse/utilities/clisrc/org/netbeans/modules/openfile/cli/Handler.java?r1=1.4&r2=1.5&diff_format=u

Created attachment 21408 [details]
patched jar-file

I attached a fixed version of .jar file "org-netbeans-modules-utilities-cli.jar".

It is not a binary patch but a complete .jar file. To test it, put it in place
of the original .jar file, i.e. to subdirectory

     ide5/core

under your NetBeans installation directory.

I think the change in utilities-cli is wrong. They cannot interpret single 
argument as a file, that would change the contract and also prevent 
cooperation with other cli handlers. 
 
Why cannot the double click invoke netbeans --open %filename? 
 

After a face-to-face discussion with Jarda Tulach, I accepted the fact that the
change is wrong so I am going to rollback the change made in the trunk (and not
propagate it to the "release41" branch).

Unfortunately, I see no way how I could fix this bug on the side of the
Utilities module. The alternative ways of fixing or "fixing" are (for example):

- make the installer to associate .java and .jsp files with NetBeans in such
  a way that the filename would be prepended with the "-open" CLI argument
- make a change in the core such the the Utilities module's CLI handler
  would always be the last applied CLI handler which would make my patch
  reasonably reliable
- just add a note to documentation and/or release notes and advice users
  how to make a proper associations (i.e. with the "-open" argument)

Reassigned to core.

I removed the patch from the trunk (rollback).

Modified file:

I integrated the patch into the trunk (as announced).

Modified file:

    utilities/clisrc/org/netbeans/modules/openfile/cli/Handler.java   (1.6)

Diff:
http://utilities.netbeans.org/source/browse/utilities/clisrc/org/netbeans/modules/openfile/cli/Handler.java?r1=1.5&r2=1.6&diff_format=u

CVS revisions:
  1.4 ... before the patch was applied
  1.5 ... contains the patch
  1.6 ... after the patch was removed

Revisions 1.4 and 1.6 are the same.

Up to the installer, IMHO.

The original issue is WONTFIX. To associate java/jsp files with NetBeans as the
default editor, the user has to pass the file via the --open option, like this:

  netbeans --open %1

Then there are several potential enhancement requests mentioned in this issue:

1. make the installer to associate .java and .jsp files with NetBeans in such
   a way that the filename would be prepended with the "-open" CLI argument

Not for 4.1, but it can definitely be considered as an enhancement of the
installer for the next version. I've filed issue #57619 to track it.

2. make a change in the core such the the Utilities module's CLI handler
   would always be the last applied CLI handler which would make my patch
   reasonably reliable

Discussed with Yarda, would require an API, but it would be useful. I've filed
issue #57611 to track this enhancement request.

3. just add a note to documentation and/or release notes and advice users
   how to make a proper associations (i.e. with the "-open" argument)

Yes. For NB 4.1, I think we should document (release note) clearly how to set up
the file associations in the system and that '-open <file>' is the way to open a
file in the IDE from the command-line.

I agree (installer enh would be correct and we need better CLI api). 
 
Minor correction: '--open <file>' is the way to open a file 
 
-open works, but is there just for compatibility reasons, we do not want to 
advertize any option longer than one character that would not begin with 
"--" (ARC request), so in documentation please use -- version. 
 

This issue could be fixed without any work in the installer, if the CLI and 
its "defaultOption" as described in issue 57611 was implemented. 

Now that issue #57611 is fixed (new command-line interface API integrated), this
issue should be fixed, too. The first official release where this bug is fixed
will be NetBeans 6.0 M4.

True, this issue is fixed, but in order to increase user satisfaction, Marek 
will also enhance the Windows installer to register NetBeans as one of the 
preferred applications to "Open With:" files with following extensions:

> xml
> dtd
> ear
> har
> jar
> war
> zip
> form
> java
> properties
> nbm
> class
> ser
> url
> pdf
> html
> htm
> gif
> jpg
> png
> xsl
> css
> jsp

so when one right clicks on icon of such file and chooses Open With... one can 
choose NetBeans 6.0 and that action will invoke NetBeans with --open filename 
parameters.

Fixed in main trunk:
/cvs/installer/libbean/src/org/netbeans/installer/PostInstallFixupAction.java
new revision: 1.5; previous revision: 1.4

I added also jpeg file extension to list. "NetBeans IDE" is used as menu item
for Open With.

I will also check if there is any conflict with file association done with
previous installer (NB 3.6).

How it is done: Details can be found at MSDN. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_perceived_types.asp
and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_perceived_types.asp

For NetBeans IDE installer creates following keys/values in registry:
1.For given extension eg. .java:
[HKEY_CLASSES_ROOT\.java]
"PerceivedType"="text"

[HKEY_CLASSES_ROOT\.java\OpenWithList]

[HKEY_CLASSES_ROOT\.java\OpenWithList\netbeans.exe]

Where value Perrceived type is either "text" or "image" for known file types. If
this value is present it is not changed by installer. Installer is defensive in
this.

2.Application netbeans.exe is registered as follows:
[HKEY_CLASSES_ROOT\Applications\netbeans.exe]

[HKEY_CLASSES_ROOT\Applications\netbeans.exe\shell]

[HKEY_CLASSES_ROOT\Applications\netbeans.exe\shell\open]
"FriendlyAppName"="NetBeans IDE"

[HKEY_CLASSES_ROOT\Applications\netbeans.exe\shell\open\command]
@="e:\\netbeans\\bin\\netbeans.exe --open \"%1\""

Open With item appears only if given app exists. So uninstaller does not modify
registry as when NetBeans IDE is uninstalled Open With menu item is not shown
anymore. Note that *--open* is used.

If anything goes wrong I need at least content of
[HKEY_CLASSES_ROOT\Applications\netbeans.exe] and content for given extension
[HKEY_CLASSES_ROOT\<extension>]. (Use export from registry editor and then save
it in Notepad as ANSI ie. not Unicode.) Given extension can be also linked to
ProgID using default value for extension key which can also define open action.
This could be registered by old installer.

sorry for reopening - but i need to clarify:
- why is open with associated to *.class files? what's the expected action? i
did not find this association after installing m4.

I do not know. I can only add/remove file type from supported list. Discuss it
offline and if there is any further requirement file it separately. Jarda do you
know answer. Is it documented anywhere?

The "open with" is supposed to be have the same as "File/Open". As far as I 
know for classfiles it opens the associated java file (if any). I suggest to 
leave this general issue fixed (I hope it mostly is) and create new less 
priority ones.