Community
Participate
Working Groups
We need to be able to register eclipse as the default editor for a file type with the OS. This will allow double clicking on a file and opening it in eclipse. This is important for being able to view a .java file in a zip etc. I don't think it should be a problem to get the file name from the command line through to the workbech application which will be able to determine what editor to use. The question is where to put it in the workspace. I think the easiest answer is to just create a "miscellaneous" project mapped to the file's location. Remember this is not a project for "real work", its just a way of allowing the file to be viewed/edited using an eclipse editor.
From Jeff M Unclear that that is satisfactory. For example, a java file will typically be buried in some package dir strucutre. Setting the project location to the dir holding the file (cannot be the file itself) would hose the package structure and its unclear if it would even compile etc. Do you really have the hooks that allow you to lauch the platform and have it run the UI application and open a particular file? I seem to remember various people complaining that htye could not run the platform and autostart their tools... Also interesting to consider what would happen if I did this to two (or more) files? New project for each? What if the file is already in the workspace? Already open in another editor?
I don't think we need to worry that the package structure is wrong. In this case we just want support viewing/editing the file. Since the workbench is the "application" we can determine which editor is needed to open the file and the correct plugins will be activated. If we detect the case that the file is already in a project (I assume we can do this) and perhaps already open then we use the existing project/editor. I realize a solution may not be perfect but without this ability users of an eclipse based java ide will be forced to use notepad to view/edit .java files when they double-click in the file system or zips
From Jeff M Why not use the same approach we use for viewing java files from the repository? Use and IStorageEditorInput (or whatever its called) and open an editor. This way you don't have to create a project etc. BTW, this feature should look for the double clicked file in the workspace once the platform starts. If it is there, it should open the IFile rather than the above behaviour. This is especially true if you use the create a project approach. It would be really annoying to use Exploder to find one of my project files, double click and then have Eclipse come up with a spoofed up project containing my file rather than just opening the real resource it already has. Actually, that wouldn't even work as the project creation would fail due to overlapping project locations... Opening with IStorageEditorInput seems like a path to happiness.
Other customers have asked for this capability.
Consider as a post 2.0 enhancement
The lack of application-to-extension association (and an Open command in the File menu) is very off-putting to users coming from virtually every other IDE but Visual Age/WSAD. Some IDEs, like JDeveloper, support parsing, compilation, etc. even on files opened from arbitrary locations; others simply don't support those features for non-project files. Either answer would be better than the current situation. (I don't think IStorageEditorInput gets you there. External files need to be editable and saveable at a minimum. Should also be able to use features like coloring and formatting that do not intrinsically depend on projects.) I'm very pleased to see you considering this enhancement. It really would make a difference to the acceptance of Eclipse.
Reopen for investigation
*** Bug 22478 has been marked as a duplicate of this bug. ***
*** Bug 34713 has been marked as a duplicate of this bug. ***
It would be great also to be able to double click a file part that is already of a project. Currently once you have located a file via the OS, you need to switch back to Eclipse and browse/search the workspace for that file. It would be great to have Eclipse open it straight away.
*** Bug 82533 has been marked as a duplicate of this bug. ***
*** Bug 98042 has been marked as a duplicate of this bug. ***
I'm marking bug 98402 as a dup so that if we solve this one we will link this scenario to it as well.
*** Bug 130938 has been marked as a duplicate of this bug. ***
*** Bug 47487 has been marked as a duplicate of this bug. ***
Hello! I'm wondering if there currently is someone working on this enhancement? Is it planned for some future release? Will it ever been achieved? The bug is opened for more than four (4 !) years now... Has it been forgotten somewhere? I think it would be a really important enhancement, also for the visibility of Eclipse and attracting new users (because it would open Eclipse to new kind of applications and interactions with other apps and with the shell). Thank you, Olivier
Moving Dougs bugs
does anyone have any idea what it would take to implement this?
I think this should be handled in the eclipse.exe. Starting a second Eclipse runtime to find out whether there's already a running eclipse instance would take too long.
We're looking at improving the launcher in 3.3 and this item definitely falls under that work.
I could imagine, on windows at least, sending a message to an already running eclipse to open a file (note that if we are using JNI to start java, bug 82518, the launcher process would no longer be spinning its own event loop), I assume the workbench would have a way to receive such a message. However, I don't know if there is an analagous mechanism for the other platforms.
FWIW, NetBeans just added this functionality. For more info see: http://wiki.netbeans.info/wiki/view/NewAndNoteWorthy#section-NewAndNoteWorthyMilestone4-OpenWithIntegrationForWindows http://www.netbeans.org/issues/show_bug.cgi?id=57364 http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-sendopts/overview-summary.html
Is this in the works? Is it possible to do this with RCP maybe? We have an editor (non JAVA) that if we could package up our plugin into an RCP applicaiton and be able to open a file by associating it to the eclipse.exe(or .app) would make the world of difference to our users.
I don't understand the need for creating a temporary project or such. Eclipse already lets you open files outside projects via File|Open File...
(In reply to comment #24) > I don't understand the need for creating a temporary project or such. Eclipse > already lets you open files outside projects via File|Open File... Matthew, that is fine. But what this bug is about is have a file (possibly associated with eclipse) to open in Eclipse when opened in the operating system windowing system, like when you open a file in the window explorer, or the mac finder. And starting Eclipse if not already started.
I can't believe this has been reported over 5 years ago. I just started using Eclipse last week and that was the first "problem" I noticed. I put it on the back burner thinking that with time I would figure it out. Today I got fed up and actually went on google for a solution, which I didn't find. No wonder. Please fix. This is such a fine product with such a ridiculous annoyance.
Has this ever been solved? is it in the plan? Its crazy that the platform doesnt support this!
Deflecting to Boris.
(In reply to comment #23) > Is this in the works? Is it possible to do this with RCP maybe? We have an > editor (non JAVA) that if we could package up our plugin into an RCP > applicaiton and be able to open a file by associating it to the eclipse.exe(or > .app) would make the world of difference to our users. In an RCP application, you can examine the command line to see if a file argument was passed in. This is possible today. It is a little more involved if you don't want to start a new instance of Eclipse (or your RCP app) if one is already running. Apart from the technical problem of detecting an already running application in a cross-platform way (I'm sure this can be solved), you need to pick a single Eclipse instance from the possibly many that are currently running, or if no instance is running, you need to determine which workspace to use.
(In reply to comment #29) > In an RCP application, you can examine the command line to see if a file > argument was passed in. This is possible today. It is a little more involved > if you don't want to start a new instance of Eclipse (or your RCP app) if one > is already running. Apart from the technical problem of detecting an already > running application in a cross-platform way (I'm sure this can be solved), you > need to pick a single Eclipse instance from the possibly many that are > currently running, or if no instance is running, you need to determine which > workspace to use. As far as the last part goes, I would say that, at least for myself, the "dumb" strategy of using the instance that was launched most recently, if there are several running, or if none are, starting one using the workspace most recently used, would be fine as an initial solution. However, there are surely smarter ways, like trying to detect a logical workspace to be used based on the location of the file you are trying to open, but I wouldn't want such a thing to delay adding this feature.
FYI, I noticed Genuitec has added this functionality as well, to MyEclipseIDE. See an example at http://www.myeclipseide.com/ContentExpress-display-ceid-98.html .
(In reply to comment #31) > FYI, I noticed Genuitec has added this functionality as well, to MyEclipseIDE. Nice. Do you know if they plan to contribute this back to Eclipse?
>> FYI, I noticed Genuitec has added this functionality as well, to MyEclipseIDE. >Nice. Do you know if they plan to contribute this back to Eclipse? That's an interesting question considering that we proposed a project at Eclipse almost 2 years ago to perform just this kind of desktop integration. Here's the proposal: http://www.eclipse.org/proposals/eclipse-desk/ We spoke to other members, the Platform team, and anyone that would listen about it but we eventually had to withdraw the proposal due to lack of support and interest from the community. As a result, we simply did the work on our own and productized it.
(In reply to comment #33) > That's an interesting question considering that we proposed a project at > Eclipse almost 2 years ago to perform just this kind of desktop integration. > Here's the proposal: http://www.eclipse.org/proposals/eclipse-desk/ Alright, that explains it I guess. You could still contribute to, say, Platform/UI - no need to start a project. But I'm just a developer, not a politician; all I know is that Platform/UI is welcoming contributors, and even has some outside committers already.
Bugzilla question: this is a fairly old bug so I'm wondering, should it still have a status of 'NEW'? According to https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status it seems like 'NEW' is a temporary state.
(In reply to comment #35) > Bugzilla question: this is a fairly old bug so I'm wondering, should it still > have a status of 'NEW'? Unfortunately, we don't have an OLD status. ;-) Seriously, the Platform/UI team does not distinguish between NEW and ASSIGNED bugs. We tend to leave bugs open rather than marking them RESOLVED/LATER or REMIND even if we don't have the resources to make real progress soon.
Does the recent activity on this bug indicate that something is going to be done regarding this high-added-value functionality? If not, what can we do to make it go up in the priority list? Eclipse is an ongoing project with lots of new functionalities in every release, so why not this one? I can't believe that a so useful functionality has not already made into the priority list of the Eclipse development team...
(In reply to comment #37) > Does the recent activity on this bug indicate that something is going to be > done regarding this high-added-value functionality? Unfortunately no, unless someone from the community steps up and provides a patch for this.
I've just been thinking about this lately due to the recently launcher rework. I'm more concerned with the case of the already running Eclipse instance to be able to arbitrarily handle commands being passed in. I'm sure the generic solution should be able to encompass all cases properly. My initial thoughts about a solution after talking to Andrew a bit involve possibly having a daemon thread running in a bundle that creates a socket and some type of file maybe persisted in the osgi instance area that has info about the socket... not sure, if people have ideas on possible implementations, feel free to post and maybe we can gather community interest.
I need this feature as well for an application with scripting capability. Currently my application loads a java src file into gnuclient or emacsclient or J. I should also support elipse. Communication over a port would be fine or special command line options would do as well. In J http://armedbear-j.sourceforge.net/ and I think in JEdit this feature is nicely implemented. Could this please be put to the top of the priority list.
for those who are still fighting the good fight, there's some discussion over here https://bugs.eclipse.org/bugs/show_bug.cgi?id=178927 on a possible solution to this type of problem
I like Chris' approach on bug #178927 of putting a generic extensible solution for "remote commands to be executed in an already running application", to be added right to the Equinox / Launcher framework. Although it's true that anybody could write his own "command sender" application and "command recipient" code on any layer (and it looks like Azureus proves it works), I don't think that Platform/UI is the right place for this. Especially for RCPs, Equinox / Launcher seems much better place for this. The Launcher is also more easily able to actually launch the application for executing commands, in case it is not already running. Could the 26 votes consider also voting on bug #178927 in order to foster this approach?
As a newish Eclipse user myself, I agree that this is really crucial to the new user experience. After using a variety of other Java IDE's that all had this functionality, it was VERY frustrating to me to not be able to do this in Eclipse. Even if this did not work for files that were already part of a project, I would be OK with that, but having to go back to the IDE and re-locate any file I am trying to look at (particularly one in a jar or zip) is a continual source of annoyance for me and others at my company. Indeed, we almost decided to use a different IDE instead of Eclipse due to frustration with this so basic and obvious missing feature. Sorry I updated this twice (adding myself to the CC and leaving this comment) but I am new to Bugzilla too.
I am experimenting with this in a new project/eclipse distro called Padclipse: http://padclipse.sf.net/ . I also suspect the best place for this would be in the launcher, because that would make launching the second instances a lot faster, although I don't know much about how the launcher works. At the moment I went for the simplest solution that I thought would work: 1) Currently, only 1 instance is allowed, so this is different from Eclipse. A file ${user.home}/.padclipse/.instance will keep track of a port number. 2) The first instance launched will detect that the file doesn't exist and open a socket and write the port number into that file. 3) The second instance detects that the file exists and tries to connect to the socket. If successful, it sends the command line parameters. NB! My impl. sends only Platform.getApplicationArgs(), I'm not sure when/how exactly it becomes apparent which args are handled by the platform. Can it be done during the launcher? 4) If the second instance fails to connect, that means the file was probably left there after a crash, and it will continue as in 2) 5) The parameters are assumed to be URI-s and converted into a File Store and opened with IDE.openEditorOnFileStore(). The file: scheme is assumed if a scheme is not present and I think some further tricks will need to be added to support the native form of paths on all platforms. 5.a) for the 1st instance launch, this is done during WorkbenchAdvisor.postStartup() 5.b) for consequent launches, this is done right when reading parameters from the socket 6) The IDE tries to find the File Store in the workspace first anyway (checking all links as well). In Padclipse a modified version of IDE always creates a link a project called "linked-files" if an existing link was not found. Actually, I'm planning to implement this as a somewhat pluggable "Workspace File Linking Strategy" so that a user could configure to some extent how the links are created. 7) On exiting, the first instance deletes the file. But I plan on improving this in Padclipse and would be happy to accept help with this and contribute back to Eclipse if it would turn out good enough. Current source can be found here, but this is very early: http://padclipse.svn.sourceforge.net/viewvc/padclipse/trunk/plugins/net.sf.padclipse/src/main/java/net/sf/padclipse/ (mostly in the singleinstance package) Note: I haven't read #178927 yet.
Created attachment 83454 [details] spam my carbide ui can not open
Comment on attachment 83454 [details] spam (In reply to comment #45) > Created an attachment (id=83454) [details] > carbide ui > > my carbide ui can not open Looks like a spammer, see bug 210560.
Hi, the following attachment contains a working solution implemented for the win32 platform. I've come to the solution for my own needs, without knowing about this bug at all. I've read only the last few comments, and surprisingly the solution is near the one mentioned in Comment #44. It consists of 2 parts: - The native 'eclipseopen' launcher. Acts as very thin layer between the shellcmd Plugin (see below) and the Eclipse launcher. - The 'shellcmd' Plugin. Communicates with eclipseopen (or any other application such as a browser) through the http protocol. Please also see the 'scenario' screenshot, contained in the attached file. I've spent quite some time creating it ;) Setup: - eclipseopen.exe must be installed in the same folder as eclipse.exe. - The 'eclipse.shellcmd.win32' Plugin must be installed. Part 1: - In Windows Explorer, associate the .java file extension with 'eclipseopen.exe' Part 2: - Clicking/opening the 'HelloFromTheShell.java' file invokes 'eclipseopen' thru the shell, passing the file name as the sole argument. - eclipseopen now searches for the first top-level window, that has the ECLIPSE_CLIENT_ID property assigned. If such a window could be found, it is brought to top and the file is opened (see below). - If no window could be found, the 'eclipse.exe' process is started (this is the reason why eclipseopen.exe must reside in the same folder as eclipse.exe...so that it can find it). - When now Eclipse starts, the 'eclipse.shellcmd.win32' Plugin is loaded and it does this: - It starts a (very basic) HTTP server. The server responds only to a "/open?file=theFile" request. The address of that server is stored in a shared memory area, named ECLIPSE_CLIENT_ID. - It assigns the ECLIPSE_CLIENT_ID to IWorkbenchWindow#getShell(), which is the top-level window, so that eclipseopen is able to find it in the case when Eclipse is already started. - After starting Eclipse, eclipseopen tries for 20sec to obtain that ECLIPSE_CLIENT_ID window property again...if found, Eclipse has finished loading the 'eclipse.shellcmd.win32' Plugin and its http server is ready to receive the open request. - Actually opens the file. eclipseopen did find the Eclipse top-level window and reads the http server address out of the shared memory area. it invokes a simple http request to open the file: http://localhost:5551/open?file=C:\eclipse\workspace\shellcmd.test\src\HelloFromTheShell.java - The http server handles the request and passes the file-value to IDE.openEditorOnFileStore(IWorkbenchPage, IFileStore). Basically the same way as org.eclipse.ui.internal.ide.actions.OpenLocalFileAction does. The way over HTTP has the advantage, that Eclipse could even open files thru the browser. And with a little more code, eclipseopen could act as an URL protocol Handler as well (see this link for details: http://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx. I do have knowledge about this...and I know it works at least with IE and FireFox. Some other thoughts: - The shell exists only once, whereas developers might have multiple Eclipses open at the same time (for different workspaces). There can only be 1 association to a file extension, so one must decide which of those several Eclipse installation is 'My Master Eclipse'. If multiple Eclipses are running the shellcmd Plugin, the first top-level window found will be activated and that might not be 'My Master Eclipse'. - I do not suggest to incorporate 'eclipseopen' into the already existing eclipse.exe launcher. Setting up the file association would be a lot more difficult...AFAIK all Eclipse launcher args are 'named', like "eclipse -data XYZ -nl en". There exists no default/unnamed argument like "eclipse c:\MyClass.java". As said, something like "eclipse -open c:\MyClass.java" would involve lots more of file association steps...we all don't want an Eclipse Installer, right? Please let me know what you think about it. I really would like to help/contribute and see that bug closed. Regards Christian
Created attachment 104405 [details] Eclipse Shell Integration (win32) See comment #47
Created attachment 104406 [details] Shell Open Scenario See comment #47
Christian, what happens when there's no Eclipse open and user has multiple workspaces to choose with so that Eclipse prompts for workspace selection when starting up? 20 seconds (or, for that matter, any arbitrary timeout) may not be sufficient for this scenario. Also, HTTP server solution brings up another matter -- there may me more useful things that might be done to Eclipse this way. For example, OpenOffice.org has its UNO remote protocol which is a very powerful solution. I think it would be worth considering what approach should be appropriate for Eclipse.
Max, this heavily depends on whether this 'open' feature would be integrated into the launcher or not. AFAIK there is some callback/notification between the laucher and eclipse (bringing down the splash screen), so this timeout thing would not be necessary. The eclipseopen prototype uses this 'polling for existence' only because it cannot receive such a 'ready' signal. The protoype also does not popup any error message boxes/log entries...it quits silently. May a message like "Eclipse did not respond to the open command in a timely fashion. Would you like to retry? [y|n]" would be approriate...but this message box would popup "suddenly out of nowhere" and I'm not sure whether this is a good thing. But prior to discuss such things, I think we (you, they?) should first decide whether to 'launcher or not'. I agree with you, that such an Eclipse HTTP server opens a whole new playground. Keeping also the RCP apps in mind, which would also benefit a lot from this 'open file' feature, we should not rely on rather "heavy-weight" RPC mechanism like UNO is. But instead, we should KISS. This new door imposes security risks, which must also be addressed, The HTTP server may only accept requests from localhost and not "from outside". It may ask for confirmation when opening an executable file. Also, Eclipse should open the given file *always* in an internal editor. For example: in the shell, my ".xsd" files are associated with "AppX". Now, for whatever reason, I want to open that file in the Eclipse text editor and not in AppX. So while I'm in the shell, I choose "Open with..." and select "eclipseopen", temporary for that file only. Eclipse opens it and figures out that ".xsd" is marked as "Open with System Editor" and it would invoke AppX for that file. This is not what is expected.
(In reply to comment #50) > Christian, what happens when there's no Eclipse open and user has multiple > workspaces to choose with so that Eclipse prompts for workspace selection when > starting up? 20 seconds (or, for that matter, any arbitrary timeout) may not be > sufficient for this scenario. > > Also, HTTP server solution brings up another matter -- there may me more useful > things that might be done to Eclipse this way. For example, OpenOffice.org has > its UNO remote protocol which is a very powerful solution. I think it would be > worth considering what approach should be appropriate for Eclipse. > Note thet asmilar yet more generic solution (ie: any command could potentially be executed in eclipse as triggered from an HTTP get url has been implemented last year as part of the summer of code @ eclipse: http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/org.eclipse.soc.ewi/ It does not provide a solution to start eclipse (ie there are no launchers whatsoever) but it has a minimalist http server dedicated to one single simple task, and deals with the issues of multiple eclipse by having coordinate themselves through http so tyaht a primary eclipse instance is known at all times.
cc'ng the Equinox faction as they should be aware of the requirement I had a partial solution in bug 178927 awhile back. The tricky part is dealing with multiple eclipse instances... it's easy if you're application is a singleton (only one instance allowed)
btw, the more votes on this bug the better. That can help the Eclipse team prioritize this.
(In reply to comment #53) > cc'ng the Equinox faction as they should be aware of the requirement > > I had a partial solution in bug 178927 awhile back. The tricky part is dealing > with multiple eclipse instances... it's easy if you're application is a > singleton (only one instance allowed) Agreed and I think there is an element towards that in the work of Michael rob @GSOC: See http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/org.eclipse.soc.ewi/plugins/org.eclipse.soc.ewi/src/org/eclipse/soc/ewi/internal/CommandManager.java?revision=1.5&view=markup and http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/org.eclipse.soc.ewi/plugins/org.eclipse.soc.ewi/src/org/eclipse/soc/ewi/internal/CommandService.java?revision=1.2&view=markup Every Eclipse instance that runs that plugin will 1/ try to start the web server on port 34567 2/ if the port is taken 9ie an ewi web server already listens there ) ... the instance will register itself with that already existing instance 3/ all instances sync up with that main instance on port 34567 4/ when a command is received from http on port 34567 , if there are several instance started that registered themselves with the main, the main eclipse instance will pop up a dialog asking the user to select which eclipse instance to execute the command in The obvious example is opening files, and that is the sample command provided: http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/org.eclipse.soc.ewi/examples/org.eclipse.soc.ewi.examples.openfile/plugin.xml?revision=1.1&view=markup Note than any eclipse command can be handled this way. The uses cases we thought about were: - assuming you have a command line client that can open a url (ie curl, or wget on linux) you can then open a file from the command line in eclipse - assuming a link on http://localhost:34567/... in some web page , you can by clicking that link (in an arbitrary web page, not necessarily local) execute some command with some uses cases such as: -- open a remote file (ie a java file) -- add an update site url to eclipse and start and automated update... ... and so on
Created attachment 106356 [details] Simple socket solution I was just playing around with this and I'm attaching a prototype solution so it is not lost. This patch is based on 3.4.0 final. It causes the IDE application to open a socket and listen for requests. When the IDE application launches, it checks for a socket, and if available writes the launch arguments to the socket and shuts down if it gets a positive response. The thread reading the socket reads the command line arguments and opens the referenced file. The code is at the IDE level because the behaviour is application-specific. Opening an editor is a reasonable default behaviour for an IDE, but not necessarily for other RCP applications. This code could certainly be refactored/generalized but I'm just throwing it out there as a proof of concept.
Created attachment 106360 [details] Simple socket solution (reformatted) I didn't have correct platform UI formatter settings, resulting in a larger patch. Here is a much smaller patch that avoids formatting changes.
We are using the same approach in rssowl and find some drawbacks doing so: - executing the launcher usually means bringing up the splashscreen which is annoying when the application is already running - there is quite a noticeable delay until the second VM has started and reached the point in the IDE (or RCP as in our case) code to communicate via sockets. I would favor a solution that goes straight through the launcher via native code.
I see a delay of about two seconds, which isn't bad. I agree this could be optimized in the launcher but it would involve writing and maintaining native socket code for N platforms.
Hello, I've written another plug-in that doesn't require, but can also provide a handling with URL's. It is also a socket solution (but only takes a part of a second to load!). The plug-in itself runs as server application, the client can be called from any shell. The Plug-in, documentation and helpers can be found here: http://www.jaylib.org/eclipse/plugins/eclipsecall/ It's designed after the proposal from IBM: http://www.ibm.com/developerworks/library/os-eclipse-rcpurl/index.html Regards Michael
Regarding Michael's comment #c60: I have it working in my RCP application now as well. Michael made a few enhancements at my request so it would be easier to integrate with an RCP application.
FWIW, I scratched this itch on my own without knowing this Bugzilla existed. Boris pointed it out to me. My solution is described here: http://community.buglabs.net/kgilmer/posts/114-Getting-the-files-into-Eclipse-steb
Nice! I especially like that bit about the BSD license :) -- given that you looked at other code for the same task before, can you confirm that you didn't copy & paste any code from elsewhere so it's really safe to consume your code under BSD? I assume that when multiple Eclipse instances with the Steb plugin are running, only the first one will be able to bind to the well-known port. But it looks like for use-case that's just fine.
Hi Martin, No, EclipseEditorHelper.java was adapted from Sunshade's FileUtil.java file, which is EPL. In fact you will see that in the comments. Also, you can define the port that steb listens on via it's preference page. So with an adapted client-side script (that took port as parameter) you could easily have multiple instances of Eclipse loading editors for files. hope that helps ken
Remy is now responsible for watching the [EditorMgmt] component area.
Created attachment 156681 [details] rough cut, untested Oleg, this is how I think this should work (but it doesn't, yet - you should talk to Andrew about launcher issues, and Kevin about the SWT event). Things left to do: - Make it work - Testing - The code is currently half-copied from OpenLocalFileAction, we probably need to define our own message rather than reusing the existing one. - The file is opened as a "local file", i.e. non-Workspace file. We should do a best-effort attempt at finding the file in the workspace. - What if Eclipse hasn't been launched yet: - test case where Eclipse would open with the welcome page - how does this play? - optional: ChooseWorkspaceDialog - should we try to guess intelligently which workspace to suggest, if there is a file pending to be opened?
(In reply to comment #66) > - The file is opened as a "local file", i.e. non-Workspace file. We should do > a best-effort attempt at finding the file in the workspace. IDE.openEditorOnFileStore already does this best-effort logic to find the file in the workspace. If it can't find one, it falls back to opening a non-workspace file. > - optional: ChooseWorkspaceDialog - should we try to guess intelligently > which workspace to suggest, if there is a file pending to be opened? I suggest not trying this, at least initially. I don't think it's possible to get this right with certainty without actually loading every known workspace to see. You could try guessing by walking up the tree looking for a parent that has .metadata as a sibling, but there's no guarantee that this indicates the project is actually in that workspace. A file can also be in several workspaces at the same time...
I agree with John. I just ran through a couple of tests with VisualStudio to see what it does. Essentially the first running instance of VS wins when opening the file. If that instance has a solution containing the file, then the open is normal. Otherwise, VS just acts as a plain source editor. I think this behaviour would be sufficient without getting too complex.
Please consider (sorry if already done) that the user could have several windows (possibly with different perspectives) open in an eclipse instance. I usually work with one eclipse instance but five or more open perspectives: Java, Debug, Team synch., Resources, Hibernate... I do completely different work in these different perspectives. When opening e.g. a java file, it would make sense that it opens in the java perspective, not in the Team synch one! Would it be possible to enable the user to specify (in options) his preferred perspective according to the file type, maybe? Then eclipse could open the perspective if not already done, or choose the right one to display to the user. IMHO it would add much to the usability, as a file opening in the wrong perspective would render the functionality totally unusable (you would have to close the view which has opened in the wrong perspective and then manually open it in the correct one).
(In reply to comment #69) > (you would have to > close the view which has opened in the wrong perspective and then manually open > it in the correct one). Good point, but not sure how good a heuristic we will be able to put in. Btw, did you know that you can drag&drop open editors from one window to another?
(In reply to comment #70) > Good point, but not sure how good a heuristic we will be able to put in. Btw, > did you know that you can drag&drop open editors from one window to another? I didn't. Thanks, good to know.
Created attachment 156974 [details] Wokbench patch I've changed Boris'es patch to work with the startup case. The new patch adds a "buffer" that accumulates file open requests and process then Workbench becomes idle. The file open part is unchanged other than making separate text messages for the "external" file open requests. Note that a very recent build with an updated SWT fragment (such as I20100122-0800) is required to see the new behavior. To open a file from the command line on Windows: <path>\eclipsec.exe -name Eclipse --launcher.openFile <qualified file name> Note: - use eclipsec.exe, not eclipse.exe on Windows for comman line launches - the "-name" argument specifies destination window that will pick up the message, "Eclipse" by default (note that capital "E"). - it is best to pass the fully quialified file names for now, see bug 300532 Note that this command will pick up any running Eclipse process, including processes that don't support remote file open requests. I'll open a bug for that, but for now when trying new functionality no "old" Eclipse processes should be running.
Created attachment 156991 [details] Wokbench patch updated As Boris pointed out, at least for now, we always receive events and do processing on the UI thread; hence, there is no need to synchronize the buffer.
I applied "Wokbench patch updated" to CVS Head. It should appear in the Eclipse 3.6 Milestone 5. There are still a number of things to do: - bug 300553 "--launcher.openFile" can pick up "old" versions of Eclipse - bug 300532 [launcher] resolve relative paths for file open - bug 300555 Allow plugin developers to register file extensions
(In reply to comment #74) > I applied "Wokbench patch updated" to CVS Head. It should appear in the Eclipse > 3.6 Milestone 5. > > There are still a number of things to do: > - bug 300553 "--launcher.openFile" can pick up "old" versions of Eclipse > - bug 300532 [launcher] resolve relative paths for file open > - bug 300555 Allow plugin developers to register file extensions I have opened the new "parent" bug 301030 for the remaining issues.
With the fix for the bug 301033 we finally have all the pieces in place. Hooray! A file can be associated with Eclipse using OS tools, just like for any other application. For instance, on Windows, use "Open With" from the Explorer and browse to the Eclipse application. Current Eclipse I-builds need "--launcher.defaultAction" argument added to the eclipse.ini file. We expect that argument to be added to Eclipse builds in M6 (bug 302192).
Verified in the build I20100309-0100.
*** Bug 60289 has been marked as a duplicate of this bug. ***
This bug should be reopened. On Ubuntu 10.10 64 bit with eclipse 3.6.1 and java version "1.6.0_20" (OpenJDK Runtime Environment (IcedTea6 1.9.5) (6b20-1.9.5-0ubuntu1), OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) the recommended syntax eclipse --launcher.openFile <path to file> does not work, even if the file has an extension that is associated with eclipse.
> This bug should be reopened. This bug has been fixed for an old version of Eclipse (3.6), so it shouldn't be reopened. See bug 315985 and bug 331122 for similar problems. Please add your steps to reproduce there.
I don't know if I can still remember to say "happy birthday" to this bug on Oct 12. But, life is not easy, especially you survived 10 years, it's a miracle. I'd like to say it right now: happy birthday!
You are grand grand grand father in this world. You made it!
(In reply to comment #81) > I don't know if I can still remember to say "happy birthday" to this bug on > Oct 12. But, life is not easy, especially you survived 10 years, it's a > miracle. I'd like to say it right now: happy birthday! It will be 11 years in October ;) Also interesting there are still 45 votes on a bug fixed over 2 years ago.
