Community
Participate
Working Groups
After a couple glasses of wine last night I decided to prototype something for an old feature request in Eclipse, opening files from the command line (#4922). After a couple of glasses of wine <b>tonight</b>, I'm going to post some code and ask for some advice from the equinox team before I forget :) First, the code is relatively simple. I defined a new bundle called 'org.eclipse.equinox.launcher.commands' which declares an extension point 'org.eclipse.equinox.launcher.commands.handlers' It allows clients to specify command handles based on a regex, like say '-file.*' This bundle simply opens a server socket on an available port and listens for commands. It also writes out a file called '.cid' in the osgi.instance.area that contains the port information. My goal for this file was to be used by the launcher of the framework to see whether there is an active instance, if so, open up a socket and pass arguments from the command line (ie., ./eclipse -file /tmp/tmp.txt). However, this approach may be flawed. To test the code, I simply created a new bundle, 'org.eclipse.ui.ide.workbench.commands' that implements the 'org.eclipse.equinox.commands.handlers' extension point via the 'FileCommandHandler' class. This class simply attempts to open a file in the workbench if it's structured in such a way that it would look like '-file <myfile>' The question I have for the equinox is team, is this the right approach? The next step for me is to modify the launcher code (possibly in EclipseStarter) to do the socket connection and arugment passing. For now, I'm testing simply via netcat and sending arguments via netcat ;) ie., nc localhost <port> -file /tmp/tmp.txt In the end, it would be nice if there was a standard way to do this in Eclipse as I know RCP developers have been asking for this feature for awhile (bug 4922)... with some clients even implementing their own solutions (ie., Azureus). The semantics of OSGi involving multiple running applications, instance areas, etc... may make this a bit tricky to implement in a nice standard reusable way. Thanks.
Created attachment 61776 [details] source code source for org.eclipse.equinox.launcher.commands and the test org.eclipse.ui.ide.workbench.commands application
I'm actually going to move this to the incubator for discussion, I don't want to inundate Tom's precious inbox as we are within smacking distance of each other with my recent office move :)
My first thought is that you could avoid changes in the startup code if you made an application of your own that did the work of talking with the other instance. However, this requires a different command line to start the 2nd instance (ie -application). In general, how is this 2nd instance supposed to know that it isn't a full eclipse in its own right and must communicate with the original?
Maybe creating an abstract IApplication implementation that does this may be useful. I was coming at an angle that would allow for a generic solution for the whole platform and RCP developers, however this may not be easy. Isn't there a way to specify cardinality for applications? Maybe if there's a cardinality of 1 for an application, that's how it would know. Or... there's a specific file in there indicating that an application is currently running and ready to accept arguments. In the end, it's currently tied to the instance area (-data).
I think I'd like to see something like mozilla does: eclipse -remote openURL("http://www.eclipse.org") eclipse -remote compareFiles("/tmp/a.txt","/tmp/b.txt") java -jar plugins/*launcher_*.jar -remote openFile("/tmp/myfile.txt") Having a single "-remote" option that takes the command to be executed as parameter seems to be a safer solution and avoids scenarios where a contributed command conflicts with commandline options added later. I like the idea of embedding support for -remote right in the launcher. Having it in the Java part of the Launcher might be a better idea than in the native part, although the native part could perhaps better use some platform specific techniques for (a) knowing if the application already runs, and finding a right pipe to it or (b) actually launching the application in case it does not run already. See also bug #186147 (which could be seen as a duplicate of this one, but I'll leave this for the Equinox wizards to decide).
*** Bug 186147 has been marked as a duplicate of this bug. ***
I like the integration with the native launcher and leaving this out of the java code. The reason is that it should be more lightweight to launch the native process, than to start the whole VM, just to pass a single parameter. I don't know what it is the status of the VM startup for latest JDK release, but I think it is still relatively slow comparing to the lightning-fast native launcher and it will use more memory, which may play an important role, because this may cause excessive swapping just to fulfill the memory requirement of the VM. Is it my information old on this subject?
I know this is for a more generic solution, but I am voting for this because I really want a way to associate .java and other such files with Eclipse so that non-project files can be opened from Windows.
(In reply to comment #7) > I like the integration with the native launcher and leaving this out of the > java code. The reason is that it should be more lightweight to launch the > native process, than to start the whole VM, just to pass a single parameter. I agree that for performance concerns it seems best to do this in native code, although. But does the native launcher have any way of knowing which arguments will be handled by the platform? Because, but correct me if I'm wrong, I think for the best native integration it should be possible to launch "eclipse <path_to_file>" (or even "eclipse <filename>", taking account the active folder). I.e. without any "-file" or "-remote".
(In reply to comment #9) > But does the native launcher have any way of knowing which arguments will be > handled by the platform? This is not necessary. Solution a) in comment #5 or b) forwarding all arguments, which are not for the native launcher itself (or does it the native launcher already?). > Because, but correct me if I'm wrong, I think for the best native integration > it should be possible to launch "eclipse <path_to_file>" (or even "eclipse > <filename>", taking account the active folder). I.e. without any "-file" or > "-remote". I don't agree. The flexibility is more important. I you want a single command solution to open a file, you can always create a shell script or wrapper executable. Sure, if it will be possible as "default command handler", it will be nice.
If someone has native code that can detect and communicate with existing eclipse applications of the right type (e.g., there may be many eclipse apps running, which one will be an important question) then it may be possible to integrate this into the native launcher. The exact form of the command line can be debated once that code is in place. In practice the usage models (at least on windows) are not CLI style but drag and drop or double clicking on a document and wanting it open with a particular Eclipse configuration. I'm not sure if either of these mechanisms have the capability of tweaking the command line that is generated when the associated application is launched.
"If someone has native code that can detect and communicate with existing eclipse applications of the right type (e.g., there may be many eclipse apps running, which one will be an important question) then it may be possible to integrate this into the native launcher." Jeff, the question is... how is this done the "right way"
Perhaps I skimmed too fast but most of what I saw being discussed here was either Java related or "what format should the command line be". The problem itself has nothing to Eclipse or Java. Assume you were writing a generic Windows app in C and wanted to a) discover an already running instance and b) communicate with that instance. My naive vision is that we just take that code and put it in the launcher (assuming it is not too big, complicated, ...) One has to believe that MSDN has some advice on this. We just don't have alot of time to do all the legwork involved in pinning down the answer. I'd certainly like to avoid developing our own story in Java. The ECF stuff might help...
True, the ability to send commands and discover running instances isn't really Java specific. What I'm trying to say horribly is whether this is something that should be provided by the framework out of the box and maybe even standardized within OSGi. I can't imagine this issue NOT coming up with the other framework implementations. In the sample source, I just open a socket on a well known port and go from there. I'm not sure what the best approach is though and was trying to ask people for feedback as OSGi makes things a bit complicated with the ability to run multiple applications within a framework instance, etc... Maybe Tom the OSGi oracle can comment. Maybe we can also discuss this at the Equinox Summit :D
(In reply to comment #11) > I'm not sure if either of these mechanisms have the capability of tweaking the > command line that is generated when the associated application is launched. On Windows at least, the command line can be anything. The provider of an Explorer action has to register himself for that action, and when doing so, he can specify a command line. To check, run a windows command prompt and type: C:\>assoc .doc .doc=Wordview.Document.8 C:\>ftype Wordview.Document.8 Wordview.Document.8="P:\PROGRA~1\MICROS~4\OFFICE11\WORDVIEW.EXE" /n /dde I'm sure that other platforms (Linux-GTK, Mac) have other mechanisms for registering apps to receive drop events. One Open Source application which provides such type of interaction is gnuclient, it's available as a commandline tool as well as a Windows registered app. AFAIK it uses Mailslots to communicate on Windows, and different mechanisms on Unix. But I do not believe this is "the standard way" of communicating. Anyways, though I'm in favor of having this in the native Launcher for best Platform integration, I'd find it a pity if the solution were restricted to Windows only. So even though I agree that a native solution should be strived for, I would not rule out any Java based one.
(In reply to comment #13) I've seen MSDN suggesting a combination of CreateMutex() and FindWindow() http://msdn2.microsoft.com/en-us/library/ms633559.aspx http://www.codeguru.com/forum/archive/index.php/t-201068.html The mutex name can uniquely identify the eclipse application.
Looks like a couple useful/interesting directions. Code contributions? re comment 14: Personally I don't think that OSGi or Java are the way to go for this capability. Yes it could be implemented but the vagaries of the various systems (how does this work on a iPaq? Nokia phone? Jasper phone?) will make this hard to manage and get right in all the different scenarios.
(In reply to comment #17) > Looks like a couple useful/interesting directions. Code contributions? Which one do you refer to?
Another related bug, but this time it's mac specific and hacks the launcher: https://bugs.eclipse.org/bugs/show_bug.cgi?id=201154
I wrote the patches for OS X that Chris mentioned. As you're designing this API on the Java side (and in the common launcher code), be aware that OS X addresses this capability in the OS itself, so it would be nice to keep any Socket stuff out of the common codebase (if that's the direction you end up going). For the Mac one, I addresses two capabilities: 1) Launching an RCP app for the first time by opening a document -- in this case, I really just made the OS X implementation behave like the Windows implementation, and that is that when you have a file association (or "Open With"), it just shoves the file names onto the commandline. As mentioned here, it is a little bit sketchy how you figure out which params are files and which are not. I went for putting files FIRST on the commandline, so that when you find a parameter with a leading "-", it's an Eclipse param. I actually left the specifics of interpreting this up to the Application. So in postStartup of ApplicationWorkbenchAdvisor, I call String[] args = EclipseEnvironmentInfo.getDefault().getNonFrameworkArgs(); and loop over the args. 2) The RCP app is already running and you double-click (or open with) a document. On OS X, there is an OS event system for notifications to apps for this. I provided an implementation of that, and i turned it into a new SWT event "ExternalOpen" where the event.data is an array of file paths. So if your application listens for that particular event, you can then respond however you prefer (it might be that your idea of Handlers might be hooked up to respond to that event). I noted on the other bug that I wasn't sure how Windows (or Linux) does the notification in #2, so I really only addressed an implementation on OS X.
See also Bug 4922, comment 55 for a discussion and solution for handling passing commands to multiple application instances running at the same time.
bug 201154 is also related.
This bug has a "plan" keyword, but P4 priority and no target milestone... I'm a little confused, what does that mean? Is anybody going to pick this up? As I have mentioned in comment 15 already, what I'd like to see is something that works like gnuclient / emacsclient -- let's call it "eclient" for eclipse client: eclient openFile("foo") should 1.) Find any running Eclipse instances on the same display. 2.1) If none, fire up a new Eclipse instance. TODO: What workspace, if any, to open? -- Could be a required additional argument e.g. -ws /foo/bar/myWS 2.2) If multiple, then disambiguate TODO: By what metrics to disambiguate? -- Again, an optional workspace argument could be used 3.) Perform the specified command(s) in the running Eclipse instance. For disambiguation, another possibility would be allowing an optional argument when starting up Eclipse: eclipse -session mySessionKey that same session key could then be used for connecting to the running instance eclient -session mySessionKey openFile("foo") The beauty of the "sessionKey" idea is that it's easy to write scripts / batchfiles which open instances as the user needs and connect to them as the user needs.
Following the long conventions of eclipse planning, all plan bugs receive the priority P4. Also there is no milestone to it because it is not committed. Btw, you will also notice the "helpwanted" keyword that has been here for a long time.
An article that may be of interest to this bug: http://www.ibm.com/developerworks/library/os-eclipse-rcpurl/index.html
Martin, any love on this one from you guys? I recall you mentioning that you may be willing to work on this ;)
+1 (!)
(In reply to comment #26) > Martin, any love on this one from you guys? Love yes, absolutely :-) So here is an idea which I had the other day. I'm wondering whether any Equinox folk could comment on that idea. * The OSGi Console provides a way for invoking stuff in a running Eclipse today: just run with -console 7777, and your Launchers can then connect to port 7777 in order to execute commands. There is even an advanced implementation of the console server which includes additional feature: http://telnetservice.sourceforge.net/ * The OSGi Console has an existing framework for adding command providers (CommandProvider). That is, the running Eclipse instance could e.g. register a CommandProvider for opening a file, or executing arbitrary key commands. A nice quick tutorial for this is here: http://blog.sarathonline.com/2008/12/using-equinox-commandprovider-to-make.html * The OSGi Console implementation has an existing parser/interpreter that converts String arguments into Commands to be executed (FrameworkConsole). Maybe good enough for converting commandline args into Java calls? So what's currently still missing ? 1.) A TCP/IP connection may not always be the preferred method of passing commands into the running app. That channel for passing commands should really be OS dependent -- or there may be multiple channels. Actually, *any* bundle should be able to acquire a service which allows it to execute commands. On Mac OS X, for instance, SWT might handle corresponding events in the event loop (see comment #20), but might also accept other commands via TCP/IP. I see that in Equinox, CommandInterpreter is a public API interface, but it does not seem to be a Service. In other words, no bundle can access it from the outside. The default implementation, FrameworkConsole, is internal. Why isn't CommandInterpreter exposed as a Service? 2.) Depending on the kind of channel from the remote into the app, Strings may not be the preferred means of having commands represented. There could be XMLRPC, or JSON, or some other more structured means of passing args. But CommandInterpreter is marked @noimplement, so clients cannot create their own variants of CommandInterpreter to pass into the CommandProvider implementations. Why can't I have my own CommandInterpreter? 3.) Why does the -console commandline arg insist of opening an ugly extra window just in order to print its port number? There should be a way of doing that slilently without extra window or output, e.g. just by writing a *.cid file in the osgi.instance.are like zx suggests in the description. If *either* (1) or (2) or (3) were resolved, it looks to me like we've got everything we need in terms of API to make this happen. Actually, porting zx's original prototype (which was using a new extension point) to using the OSGi CommandProvider API instead should be quite straightforward... I have some more ideas e.g. what the actual commandline args could look like, what kinds of standard commands could be contributed, and how the "right" application for executing a remote command could be found from a number of concurrently running apps (we could, for instance, contribute a CommandProvider command "_identifyApp()" which returns an ID that must match the ID of the remote invoker). But those additional things may wait until later if we agree that the OSGi console framework may be used for such endeavors. Thoughts?
(In reply to comment #28) > Why isn't CommandInterpreter exposed as a Service? I could imagine that there are security implications. The console is a powerful tool. You can uninstall or install bundles. I don't like to give this permission out to *all* bundles. It may get very complex if you need to introduce command execution permission depending on the requesting party.
Well I guess I'd counter that anybody who calls Eclipse with the -console argument today introduces the very same security hole today. Also, if I look at PDE Plug-in Registry, it allows starting and stopping bundles today so it looks like from inside the App, the very same "security hole" exists today... One option of mitigating security problems would be if CommandInterpreter were not @noimplement. Then an RCP author who wants to give secure remote access could write their custom CommandInterpreter which for instance listens on an SSLSocket only for authentication, and forbids execution of certain commands based on a Policy (or other way round, allows execution of certain commands only).
1) Can some empowered user (Chris? You filed it ...) change this to be all platforms, no just PC/XP? Same problem exists for Macs too. 2) One other channel for Macs might be Apple Events ... I mention it here as an alternative channel to be mooted at the design implication issue stage rather than necessarily something that might happen.
Re: Alex's #2: See Bug 201154
*** Bug 278210 has been marked as a duplicate of this bug. ***
I really like some of the comments on this enhancement. There seems to be a larger picture emerging here, in terms of all the required features. It doesn't sound trivial, but I hope this does not delay implementation much longer; this request has already been posted in 2007 (!). One compelling argument that I would like to make is that with better 'desktop integration' or 'operating integration' we can substantially lower the learning curve of some Eclipse products. E.g. getting people started with Buckminster by just having them click a link on a web site. Fill in your own idea <here/>. I'm also concerned about security and that's why I think regular network sockets are not a good idea. The only common interface on all the supported platform seems to be POSIX IPC, yet the Java common runtime doesn't support most of those features (named pipes, semaphores, message queues, domain sockets, shared memory). There has been work by 3rd parties to build a library to support this; I know of two instances. One particular implementation detail of one of those libraries is the 'pseudo' shared memory implementation, which just relies on a temp file on the file system, without any native calls in the Java part. The eclipse.exe executable would just append the argument line to the file, allowing other processes to read it. Apart from message passing to the Eclipse process (with the intent to open a file), we should take the opportunity to extend this feature to allow message passing between multiple Eclipse instances, and other native processes. The semantics of the handlers should be pluggable (extension point). What's the reason for the hold-up? Technical Risk, Resources, ...?
Priority and resources are the main limiting factors. To be honest I don't see this being done next year either. Someone will have to step up to it.
I would also very much like this feature, I use this all the time working in my old editor jEdit. It was implemented using a simple socket listener and an executable shell script. Surely a simpler approach would be to provide a simple socket listener that listens for files on a given port, and opens them as the socket is written to. Here's the part of the script that talks to the IDE: #SendTojEdit passes the files over a socket to a #running jEdit instance. It looks up the port and key #in the server file. If it cannot find the server file, #or if the connect fails, it returns -1. Otherwise it #returns 0. sub SendTojEdit(@args) { my @args = @_; my ($dummy, $serverPort, $serverKey); #key and port from jEdit's server file #open the server file open(SERVER_FILE, $myVars{"JEDIT_SERVER_FILE"}) or return -1; #no server file so launch jEdit #Read the character 'b' $dummy = <SERVER_FILE>; return -1 if(!defined($dummy)); #Read the port and key from the server file $serverPort = <SERVER_FILE>; return -1 if( (!defined($serverPort)) || $serverPort !~ /^\d+$/); #return bad if undefined or not a number chomp($serverPort); $serverKey = <SERVER_FILE>; return -1 if( (!defined($serverKey)) || $serverKey !~ /^\d+$/); #return bad if undefined or not a number chomp($serverKey); #setup our socket my $iaddr = gethostbyname('localhost'); my $proto = getprotobyname('tcp'); my $paddr = sockaddr_in($serverPort, $iaddr); socket(SOCK, PF_INET, SOCK_STREAM, $proto) or die "socket call failed!\nError: $!\n"; connect(SOCK, $paddr) or return -1; #return bad if connect fails #nab our dir my $myDir = cwd(); #construct the BeanShell script my $script = "EditServer.handleClient(true, \"$myDir\", new String[] { "; my $i = 0; foreach my $arg (@args) { if($i > 0) { $script .= ","; } $script .= "\"$arg\""; $i += 1; } $script .= " });\n"; #send the server key as unsigned long in "network" (big-endian) order print SOCK pack("N", $serverKey); #send the script as Java-UTF-String print SOCK pack("na*", length($script), $script); close(SOCK); #this will flush too return 0; #we are good }
(In reply to comment #36) > It was implemented using a simple socket listener and an > executable shell script. That looks like perl? We need an implementation for all the platforms (win32, linux, macosx, solaris, hp, aix) without requiring 3rd party libraries that aren't necessarily going to exist on the users computer. (If there did exist some small library we could ship on all platforms we would need to get IP approval from the foundation.) Another possibility is shared memory which we already have for all platforms. We would need a way to publish the handle so that other processes can discover it.
I see there has been lots of discussion about what technologies to use etc. and I may be missing something but there are some of us that are currently using a solution that works for us provided by Michael Schulte: https://bugs.eclipse.org/bugs/show_bug.cgi?id=4922#c60 I am using it on Windows (native .exe) and Linux (simple shell script). It seems to me that if his implementation were rolled into eclipse.exe we would be done. At least as far as the shell integration and opening a single file was concerned.
Created attachment 153004 [details] Proposed Patch for equinox launcher. Attached is a patch for gtk and win32 launchers to handle file associations and enable clients to write single instance apps. The code relies on changes in SWT which I will attach to a related SWT bug (bug 201154). For the patch to work the launcher's getOfficial() function needs to return the same value that is set in SWT's Display.setAppName() function. I've used the command line argument '-file' to specify the file to be opened. Feel free to change it (or anything else). When SWT receive notification from the launcher it will post a new SWT.OpenFile event to notify client. Clients will need to add the SWT listener early, preferably before they call readAndDispatch() to be sure that no events are missed.
(In reply to comment #39) > Created an attachment (id=153004) [details] > Proposed Patch for equinox launcher. > > Attached is a patch for gtk and win32 launchers to handle file associations and > enable clients to write single instance apps. The code relies on changes in SWT > which I will attach to a related SWT bug (bug 201154). > For the patch to work the launcher's getOfficial() function needs to return the > same value that is set in SWT's Display.setAppName() function. > I've used the command line argument '-file' to specify the file to be opened. > Feel free to change it (or anything else). > When SWT receive notification from the launcher it will post a new SWT.OpenFile > event to notify client. Clients will need to add the SWT listener early, > preferably before they call readAndDispatch() to be sure that no events are > missed. Do you have an example client for this? Is SWT.OpenFile the best event name for this?
> Do you have an example client for this? I have created file associations on my machines and can launch eclipse and can prove that the event is sent. There is no workbench support for this yet so the demo is not very exciting. > Is SWT.OpenFile the best event name for this? Yes, it is. :-)
I have an RCP app that is written with my own implementation of this feature (though I only did an impl for OS X) that I could probably pretty easily retrofit to demonstrate this if it would help. It's implemented in a pretty similar way.
(In reply to comment #41) > > Is SWT.OpenFile the best event name for this? > Yes, it is. :-) I'm only ask because people will use this functionality for things other than opening files and wondering if a generic name is more suitable. Can you post your sample code Kevin :)? That could be the start of closing bug 4922... which may give you the prize of closing the lowest bug # this year.
Eclipse is my sample app. I made file associations such that *.foo files are "opened" by Eclipse. When I say opened, I mean that the messages are received by SWT and the event is posted. Nobody is currently listening for the event so it's not a very sexy demo. Also, I haven't released the SWT changes that go along with this patch yet. I'll have the SWT code finished this week. Once the SWT and launcher changes are released, I'll work with the workbench guys to get things working for Eclipse and we can document this properly via blogs, wiki or whatever. I don't know what else this is going to be used for. We (the SWT team) discussed the name of the event and decided OpenFile was the most appropriate name since the event is intended to be used as a notification that a file should be opened.
(In reply to comment #44) > I don't know what else this is going to be used for. We (the SWT team) > discussed the name of the event and decided OpenFile was the most appropriate > name since the event is intended to be used as a notification that a file > should be opened. I think what Chris was talking about was something like a mediator between the launcher and SWT. Right now the solution is very customized to the "open file in running Eclipse instance" issue. However, the bug summary is more broaden, i.e. it also targets the "send shutdown command to running OSGi server instance" problem. I wonder if it is possible to generalize this native inter-process communication? For example, the Sun JDK already comes with tooling to find running JRE instances and to communicate with them. I wonder if there is some JVM API for this which the Equinox launcher could use to send messages to Equinox. In Equinox would be some general listener for those messages. This guy delegates the incoming message (eg. "open file XYZ") to the appropriate message handler (eg. "SWT OpenFile handler").
Created attachment 153399 [details] new patch... includes carbon and cocoa Attaching a new patch. No changes to win32 or gtk code, just added some new code for carbon and cocoa platforms.
In the native launcher there are two major problems that need to be solved, discovery of the running eclipse, and communicating with it. This patch does both and requires SWT to do it. For this reason it will not be a general solution. Given that most eclipse client base applications are likely to be SWT based we feel this solution solves at least 80% of the cases. We recognize that this is not a general solution for sending events to non-SWT based applications but given the fact that the equinox team does not have the resources right now, we can take this patch for opening files or we can sit around talking about a general solution for another few years. We also do not think this solution prevents us from adding a general solution later. Using the -file option to the launcher makes this very specific to opening a file and can allow for something more general to be added later. To the patch itself, based on an initial look at the win32 parts: 1) "-file": There is a general problem of stealing arguments that are already used by products above us. We likely need to use something more like "--launcher.openFile". (We started the --launcher convention in 3.3, see bug 174189) 2) There are two timeout values, wait for the mutex, and wait for the SWT window, both are 60 seconds. This may not always be long enough, see for example bug 225150 and duplicates. We need an argument to control this. 3) In a truly headless launch, we will never load SWT and never spin the event loop. In this case the mutex would never be released causing subsequent launches to wait until timeout. We'll need to only do reuseWorkbench & mutex if we know we want to, either tie it to -file, or add a second argument to control this. If we just tie it to the -file, then there is a window where a file open would cause a second eclipse to start since if the first eclipse is just starting up and didn't have the -file argument. 4) Early startup splash screen using StartupMonitor will need to account for this since they will get the swt even before the workbench application is even started. (Is it possible for them to just keep reposting the event until the workbench takes over?)
Comment on attachment 153399 [details] new patch... includes carbon and cocoa Removing iplog+ flag - this should only be added at the time a patch is released into CVS
Created attachment 153545 [details] updated patch Updated patch - change to --launcher.openFile - add --launcher.timeout : not sure we really need two separate timeout args. Gtk & mac still need use use this value. - only do reuseWorkbench if --launcher.openFile was specified, might want to change this to be a separate argument - gtk needs to be made dynamic (bug 201414), started doing that, still need to replace the GDK_DISPLAY macro and verify I got the libraries correct Gtk stills needs some loving to clarify what is going on, (maybe renaming functions), I was a little confused when I first started looking at it. Note also, we have no implementation for wpf or motif.
Created attachment 155560 [details] updated working/tested on linux.gtk.x86. Needs testing on windows, macosx needs reviewing. The mac part of the patch has changes to both cocoa & carbon, it may be possible to reduce this to one set of changes that works on both.
Comment #0 was about opening files from the command line, which we now do (bug 4922 is marked as fixed). We realize we do not have a general solution, but have no plans to do anything further. I was never convinced that the general solution for communicating between eclipses belongs in the launcher (demonstrated by the fact that Chris' original prototype was entirely java). Marking this as fixed in 3.6. New bugs should be opened for any additional specific requirements.
