Community
Participate
Working Groups
when i drag a file and drop it over the editor are the file should get opened
yes, but it should work for all editors not only Java - not for 2.0
Reopening for 2.1 consideration
The workbench supports this in 2.1.
I've tried it in 2.1.1 and it does not open the file...
I think Adam is referring to dragging a file from the desktop, and Nick is referring to dragging a resource from the Resource or Package Explorer. Now that Eclipse 3 can open external files, dragging from the desktop would be a nice feature that many other programs already have. See the Fileopen plugin (eclipsepowered.org) that sort of does this for 2.1, or Windows programs like Textpad and Internet Explorer.
*** This bug has been marked as a duplicate of 21973 ***
closed wrong bug
*** Bug 36606 has been marked as a duplicate of this bug. ***
Jbuilder does this too. You just drag a file from explorer (in Windows) to the text area and it opens. It has full syntax highlighting and error reporting that depend on parsing of the file. No symbol lookup or refactoring is available.
Bug 21973 (which was marked as a dup of this bug) included a request for supporting OS file associations with Eclipse. For example, under Windows we'd like to double-click on a Java file on the Desktop and have it invoke Eclipse if it's not already invoked and open an editor on that file. Right now, when I do that on my computer it invokes Visual Studio.Net :-O. Question: Do you want a separate bugzilla entry for that or is the intent that that enhancement request be lumped in with the drag-n-drop one? If the latter, then can the title of this one be changed to reflect both drag-n-drop plus file associations? Note: We're not just talking about text editing. For example, if you drag or double-click a .xsd file you would want the graphical XSD editor to come up. (Also, what does "[misc]" in the title mean, and wouldn't platform/ui be a more appopriate home for this? Just wondering.) Thanks.
>Question: Do you want a separate bugzilla entry for that Yes, please. >Note: We're not just talking about text editing. For example, if you drag or >double-click a .xsd file you would want the graphical XSD editor to come up. This would be a general Platform UI bug. >(Also, what does "[misc]" in the title mean, and wouldn't platform/ui be a >more appopriate home for this? Just wondering.) Once a bug ends up in JDT or Platform Text land we sub-categorize our bugs into categories (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/bug-annotation.htm). HTH Dani
Moving to Platform UI.
Doh! I already entered Bug 47487 (Support double-click on a desktop file to open it in Eclipse) so that's covered.
*** Bug 58943 has been marked as a duplicate of this bug. ***
See also bug 37935 for the feature to open an external file (via the menus). Currently the WorkbenchAdvisor can extend the handlers for DnD in the editor area via IWorkbenchWindowConfigurer.addEditorAreaTransfer(Transfer) and configureEditorAreaDropListener(DropTargetListener). However, since the "open external file" functionality is provided by Text, which is above the IDE plug-in, we can't register the appropriate Transfer and listener in the IDEWorkbenchAdvisor. It would be better to contribute editor area DnD handlers via extension point. This requires new API.
I see two implementation stages: 1) Make it work in the IDE, and 2) Make it work for non-IDE RCP apps. The first is easier and can be done quicker so I suggest going ahead and doing that now. The second would seem to require TextEditor and buffers and the open external file action to be RCP-ized, which is a good idea but shouldn't hold up making it work in the IDE first (unless it's way easier than I think it is).
*** Bug 68167 has been marked as a duplicate of this bug. ***
Moving Dougs bugs
Unfortunately, I don't have time for this but this (drag and drop) seems not so hard to do : - this feature would be equivalent to "File -> Open file -> Open" feature, so there is no bad surprise. - a plugin already implements this : FileDrop http://sourceforge.net/projects/shiningaffix
*** Bug 169232 has been marked as a duplicate of this bug. ***
Created attachment 57644 [details] modified class from 3.2.1 release Here is a begining of resolution. The second part of the resolution is to find how to obtain an IFile object from a file which is not in the workspace.
Created attachment 57646 [details] modified class from 3.2.1 release Here is a begining of resolution. The second part of the resolution is to find how to obtain an IFile object from a file which is not in the workspace.
Here is the first part of the resolution : I've managed to implement drag and drop. On the other hand, there is still one thing I can't do : obtain a valid IFile for a file which is not in the workspace. I had to add a dirty code to skip the problem. I have gather this dirty code in ONE method (crummyCodeToReplace). You can find the modified classes in attachment : - EditorAreaDropAdapter.java - IDEWorkbenchWindowAdvisor.java Since I've used eclipse-sourceBuild-srcIncluded-3.2.1.zip, this code has been coded for 3.2.1 . Unfortunatly, I've seen that IDEWorkbenchWindowAdvisor.java have been recently moved so my code need to be adapted. I will try to recode with CVS version later. Any reaction ?
Please provide patches instead of full source files...
Created attachment 57654 [details] patch of EditorAreaDropAdapter.java Sorry, here are the patches from 3.2.1
Created attachment 57655 [details] patch of IDEWorkbenchWindowAdvisor.java I have one question : How we can obtain an IFile for a file which is not in the workspace ? This should be possible since we can open any file with the menubar.
Passing to Boris to examine the patch.
What's new ? I recapitulate important informations : - the patch was made on 3.2.1 build release - the patch is working but the work is half-done My two questions : - How to obtain an IFile instance for a file which is not in the workspace (as when we open a file with "File -> Open" in the menubar) ? - Where has the code of IDEWorkbenchWindowAdvisor.java been moved in the current release ?
(In reply to comment #28) > - the patch is working but the work is half-done > - How to obtain an IFile instance for a file which is not in the workspace > (as when we open a file with "File -> Open" in the menubar) ? org.eclipse.ui.internal.editors.text.OpenExternalFileAction in org.eclipse.ui.editors > - Where has the code of IDEWorkbenchWindowAdvisor.java been moved in the > current release ? The IDE application has been moved into its own plug-in org.eclipse.ui.ide.application.
*** Bug 138137 has been marked as a duplicate of this bug. ***
The patches in bug 138137 that I just marked as dup of this one are pretty close to the solution. Boris I'm moving this to Eric who had the dup in his bucket for M6.
Created attachment 59046 [details] Final Fix This fix depends on upcoming changes in Platform Text.
Note that the fix adds a new method IDE.openEditorOnFileStore(...). This is to avaid bug 148844 which will most likely not be fixed for 3.3. I thought a longer name is better than e.g. openEditor2(...).
The changes to IDE from the 'Final Fix' can be excluded when applying the patch since this has already been committed to HEAD.
Committed in >20070316. I now dispose -any- existing drop target before creating the new one. I've been in discussion with the SWT team regarding the solution to this defect (which is to gain access to the current DropTarget for a control using 'internal' knowledge) and we have agreed that we'd rather go with this solution for now and that post 3.3 we'll come up with a more viable SWT API for drag and drop in general...
Verified in 20070321-0010. Ran the readmetool example which was failing before this defect was fixed (it was adding a MergedDropTarget of its own and the TextEditor was adding its own...
(In reply to comment #34) > The changes to IDE from the 'Final Fix' can be excluded when applying the patch > since this has already been committed to HEAD. > Seems like _only_ the changes to IDE were committed. In 3.3M6 I still cannot drop a file from the Windows Explorer onto the editor area. And the source from CVS does not contain the changes of the patch except for the IDE class.
Correct, "Committed in >20070316. " seems to be a wrong statement or ended up in the wrong bug report - I wonder how "Verified in 20070321-0010. " happened ;-) Neither IDEWorkbenchAdvisor nor EditorAreaDropAdapter have been fixed.
Sorry, I slipped a gear; mixing this up with a defect regarding the text DnD (which is what comment #34 and #35 are about). Dani, I'can apply the patch tomorrow to check it out. Are the Platform Text changes in place ?
Yes, everything is ready. Just go ahead and apply the patch (exclude IDE.java as this is already in).
OK, try 2...;-) Committed in >20070425. Applied he patch (thanks Dani!). Tested by dragging a .txt file from the WIndows Explorer into the workbench...voila, file opens
Verified in I20070501-0010.
