Community
Participate
Working Groups
With the current changes from bug 178927, you need to pass a command line argument "--launcher.openFile" followed by the file name to get it to open. (Except on the Mac, where opening a file does not go though the command line) This is not good enough, because - at least on Windows - there is no good way for end users to get file types of their choice to open in Eclipse. They would either have to change the Windows registry themselves, or add "--launcher.openFile" to the eclipse.ini file, making sure it is the last entry before the "-vmargs" part. We need a solution that makes "Open With" work for the Eclipse SDK.
What about using a special launcher exe (similar to emacsclient / gnuclient) just for handling the "open file" requests?
(In reply to comment #1) > What about using a special launcher exe (similar to emacsclient / gnuclient) > just for handling the "open file" requests? Yes, that would be one option. Another option (I think) would be a slightly different semantics for the existing launcher option - instead of requiring the next argument to be the file name, take the presence of that option as an indication that anything coming from the command line (i.e. not the .ini file) should be interpreted as files to be opened. Things like -consoleLog, -data etc. would have to go in the .ini file. Any other ideas?
A small tweak to Boris's idea. The --launcher.openFile file could indicate that we need to open a file. It could use something like the following: 1) If the next argument does not start with '-' then assume it is the input for --launcher.openFile. 2) Otherwise look at the last two arguments (not in the eclipse.ini); a) if the last argument starts with '-' then ignore the --launcher.openFile option. b) otherwise; if there is only one additional argument then use that for openFile. c) otherwise; if the the second to last argument starts with '-' then ignore openFile. This still has issues if someone uses the options that take no argument though. For example: eclipse -console <path to file> That would assume <path to file> was a parameter to -console. But something like this would work: eclipse -console -data <path to workspace> <path to file>
Tom, what about the case where someone tries to do: eclipse Foo.java Bar.java and expects it to open both files? Similarly, you can multi-select files (of the same extension) in Windows and use Open With from the context menu.
(In reply to comment #4) > Tom, what about the case where someone tries to do: > > eclipse Foo.java Bar.java > > and expects it to open both files? Similarly, you can multi-select files (of > the same extension) in Windows and use Open With from the context menu. Good question. Does the current launcher option allow for multiple files currently? We could add another tweak like this: 1) If the argument after --launcher.openFile does not start with '-' then assume it is the input for --launcher.openFile. 2) Otherwise look at the rest of the arguments (not in the eclipse.ini) using something like the following (forgive my explanation with java code) :) String[] args = getNonINIArgs(); LinkedList openFiles = new LinkedList(); for (int i = args.length - 1; i >= 0; i--) { if (args[i].startsWith("-") { if (!openFiles.isEmpty()) openFiles.removeFirst(); break; } openFiles.addFirst(args[i]); } // use openFiles list as the argument for --launcher.openFiles Basically we look from the end of the non-ini args until we reach the beginning or hit an option that starts with '-'. So the following would work OK: eclipse <path 1> <path 2> ... <path n> eclipse -data <path to workspace> <path 1> <path 2> ... <path n> But something like this would ignore <path 1> eclipse -consoleLog <path 1> <path 2> ... <path n>
Hm, I understand that compiling a separate native EXE just for the sake of file loading is less cool than re-using the existing EXE. On the other hand, the proposed tweaks to commandline parsing also look odd. I would not be too concerned about the multi-select. When I pick 3 GIF images and do "Open With > Firefox", or "Open With > IrfanView" I also get only ONE picture opened. Boris, I don't yet exactly understand the problem description. Is your point that you'd like eclipse.exe to open files when there is no commandline argument at all? Right now, the semantics of eclipse.exe are that -vmargs eats commandline args until the end -application foo.bat allows the app foo.bar to read commandline args -without any of these two, the defined Product is the implicit application to be started, and thus the product may decide how to deal with commandline args that are not options. Along these lines, I would suggest the following solution: * If there is *any* commandline arg that starts with a dash, treat the entire commandline as today (no special handling). * If there is *no* commandline arg that starts with a dash, we expect the installed Product to be responsible for commandline args. * The installed Product should be able to customize the Launcher policy with respect to handling commandline args. It does so with a special setting in eclipse.ini, for instance: --launcher.argumentPolicy=openFile or --launcher.argumentPolicy=passThrough In order to guarantee backward compatibility for products other than the Eclipse SDK which also use the Launcher, I think that in the absence of a --launcher.argumentPolicy, the passThrough semantics should be assumed.
(In reply to comment #6) > In order to guarantee backward compatibility for products other than the > Eclipse SDK which also use the Launcher, I think that in the absence of a > --launcher.argumentPolicy, the passThrough semantics should be assumed. Sounds like what I proposed in comment 2 (but with a different name for the option, it's much clearer). I think Tom tried to come up with a variant of this idea that would allow users to continue to pass command line argument (like e.g. -data, or -consoleLog) without having to edit the ini file. For example, anybody using a .bat file to start Eclipse with additional arguments would have to react if we added --launcher.argumentPolicy=openFile to the SDK's ini file.
Another option products have is to create a separate ini (e.g. eclipseOpenFile.ini) and copy (or link) the existing exe to one that matches the new ini file (e.g. eclipseOpenFile[c].exe). This way the eclipseOpenFile.ini can have any special options we want without changing the behavior of the original exe. Would this simplify the problem any?
(In reply to comment #7) > e.g. -data, or -consoleLog) without having to edit the ini file. For example, > anybody using a .bat file to start Eclipse with additional arguments would have > to react if we added --launcher.argumentPolicy=openFile to the SDK's ini file. I don't think so, since I propose that if *any* option with a dash is on the commandline, the --launcher.argumentPolicy would not be used. This is simpler and clearer than Tom's approach. The rationale behind my more radical suggestion is that if I'm able to add any option I'm either tweaking the registry (so I can add an explicit --launcher.openFile if I want), or I am calling Eclipse from a script (so we should be backward compatible). The one and only case to be addressed in this scenario seems to be the case where eclipse.exe is started *only* with arguments but without any options. Using the "openFile" semantics is OK in this case unless the product wants something else.
(In reply to comment #9) > I propose that if *any* option with a dash is on the > commandline, the --launcher.argumentPolicy would not be used. This is simpler > and clearer than Tom's approach. Thanks for explaining again. This makes sense to me (and is sufficiently easy to explain). +1
(In reply to comment #10) > (In reply to comment #9) > > I propose that if *any* option with a dash is on the > > commandline, the --launcher.argumentPolicy would not be used. This is simpler > > and clearer than Tom's approach. > > Thanks for explaining again. This makes sense to me (and is sufficiently easy > to explain). +1 I agree that this is probably the best option we have so far. But I am still concerned about adding --launcher.argumentPolicy to the eclipse.ini for the SDK. The SDK can have any number of applications installed. Who are we to assume that no other applications installed into the SDK (or any EPP in Helios) wants to process the commandline arguments (even if there are no '-' options)? Are we suggesting that the arguments would continue to flow through to the application? I think that is required. And we would still do the openFile operations for the arguments but there will not be anything registered to handle the openFile event from SWT unless the application explicitly decided to handle it, correct?
Hm, my assumption was that if no -something arg is on the commandline, there can also be no -application arg and therefore the product (==default app) is free to define what to do with the args. Essentially, the --launcher.argumentPolicy option would only define what to do with a commandline like eclipse.exe foo bar yoyo.java which contains no -option at all. Perhaps a yet better name for the launcher would be -- --launcher.defaultAction=openFile to indicate that this is the action to perform on the argument list when there is no other option or application or something that tells the launcher what to do?
(In reply to comment #12) > Hm, my assumption was that if no -something arg is on the commandline, there > can also be no -application arg and therefore the product (==default app) is > free to define what to do with the args. > > Essentially, the --launcher.argumentPolicy option would only define what to do > with a commandline like > eclipse.exe foo bar yoyo.java > which contains no -option at all. > > Perhaps a yet better name for the launcher would be -- > --launcher.defaultAction=openFile > to indicate that this is the action to perform on the argument list when there > is no other option or application or something that tells the launcher what to > do? This sounds fine and is easy to explain. We need to investigate what PDE does with the target ini file (if anything). For example, when exporting a product from PDE we need an option to add this to the generated ini. For launch configurations does PDE use the target ini file and will it use the --launcher.XXX option?
(In reply to comment #13) > We need to investigate what PDE does with the target ini file (if anything). I don't think that this is an issue. In my understanding, semantics of eclipse.exe remain exactly as they are today for the case of launching an Eclipse/Equinox application. The one and only change is that rather than having a separate "eclipseopen.exe", we also re-use the same eclipse.exe for opening files from the command line in the very special case that a --launcher.defaultAction=openFile instruction is there. In other words, this special option makes the eclipse.exe run in a special mode which is very different from launching an Eclipse app. Since this special "mode" of eclipse.exe only makes sense when running from the commandline with a list of files, I do not think that the PDE exporter needs to export that option or otherwise use it or know about it in launches.
(In reply to comment #14) > Since this special "mode" of eclipse.exe only makes sense when running from the > commandline with a list of files, I do not think that the PDE exporter needs to > export that option or otherwise use it or know about it in launches. I think I agree but want to make sure PDE is not using the ini file from the SDK installation to somehow populate the ini for an exported RCP product or for launch configuration.
Ah, good point -- I agree that the template ini for RCP's should not have this setting.
It is also possible to associate "Open With..." with a shortcut (or batch file). In this case, if the shortcut/batch file adds extra arguments, those will show up as being on the command line. I would suggest a modification of Martin's idea so that if the command line contains "--launcher.openFile", then everything on the command line after that will be treated as a file, but we are allowed '-' arguments before the openFile. If "--launcher.openFile" is not present, then things are treated according to --launcher.defaultAction. Note also, that all changes to the behaviour here will also apply to gtk.
(In reply to comment #17) Yes, I agree with Andrew's suggestion -- I had actually expected that the semantics for --launcher.openFile on the commandline were already in place like this and we'd only care for the case of no dash args whatsoever here.
(In reply to comment #13) > We need to investigate what PDE does with the target ini file (if anything). > For example, when exporting a product from PDE we need an option to add this to > the generated ini. For launch configurations does PDE use the target ini file > and will it use the --launcher.XXX option? PDE only considers the VM args in the eclipse.ini to use as default VM args when launching a target platform. We do not use the --launcher.XXX option.
Created attachment 158354 [details] current patch
Created attachment 158356 [details] test - win32 fragment binary Here is an eclipse_1305.dll based on the attached patch if people want to try it out. (The patch itself needs work for gtk which I'll do Monday). Copy this into the org.eclipse.equinox.launcher.win32.win32.x86 fragment from I20100202-0800 or newer. Edit your eclipse.ini, add: --launcher.defaultAction openFile You can associate eclipse with "Open With", or associate a specific file extension. Notice if you associate a file to always be opened with eclipse, it gets a little eclipse-document icon. For files always opened with eclipse: - double click, or right click -> open works nice - multi-select multiple with the same extension and hit enter, or right click -> open, works and opens all files in the selection For "Open With", this works fine, though multi-selection will only open the one file under the right click. On the command line, "eclipse file1 file2" works and opens both files. Relative paths are resolved against the current working directory. This is reusing some existing code, so if the file isn't in the working directory, it will also try to resolve against the eclipse program directory. ie, if eclipse was on your path, you could probably do "eclipse eclipse.ini" anywhere. Also, --launcher.openFile now accepts multiple arguments that don't start with '-': eclipse --launcher.openFile file1 file2 -console -debug although if eclipse was already running, it would get reused and those extra arguments mean nothing.
I have released the changes and recompiled everything for the IBuild. I also raised bug 302192 on releng to add --launcher.defaultAction to the eclipse.ini This set of changes also fixes bug 300532.
