Community
Participate
Working Groups
Being able to drag-and-drop a source file from another Windows app into the editor would be a definite improvement to Eclipse source code editor. Such feature is commonly available among source code editors.
*** Bug 146860 has been marked as a duplicate of this bug. ***
*** Bug 146630 has been marked as a duplicate of this bug. ***
Created attachment 44946 [details] Patch to add Drag and Drop of external files This patch also includes a first-cut at moving the current 'Open File' logic out of the texteditor package and into the IDE.
Created attachment 44947 [details] Patch to add Drag and Drop of external files This patch also includes a first-cut at moving the current 'Open File' logic out of the texteditor package and into the IDE.
Tod / Daniel, can you check out the patch and see if it's on the right track...? Note that it will introduce a compile error into org.eclipse.ui.examples.readmetool that I'm not sure how to handle (re-export the new dependencies from the IDE ?) so you might check out that project before applying the patch. Thanks folks...
The compiler errors that get introduced are caused by bug 148844 in the compiler. For now the change is binary compatible but not source compatible until said bug gets fixed. Here some other things that I saw at a first quick glance: - I would use IFileStoreStorage instead of IFileStoreFileStorage - writing to console should be removed before committing the patch More to comments tomorrow.
>I would use IFileStoreStorage instead of IFileStoreFileStorage I just noticed that this isn't an interface. We should do it like with the FileEditorInput which implements IFileEditorInput: simply call it FileStoreStorage and call the editor input FileStoreEditorInput.
Thanks Daniel, good feedback. Tod and I are going to see if we can come up with some approach to the dependency propagation since it seems to be a general problem that has come up before during this type of API enhancement.
>"org.eclipse.ui.DefaultTextEditor"; //HACK!! EditorsUI.DEFAULT_TEXT_EDITOR_ID; //$NON-NLS-1$ This hack can be replace by: IDEWorkbenchPlugin.DEFAULT_TEXT_EDITOR_ID
Wait: even better: the code you copied from the OpenExternalFileAction is quite outdated. You can use IDE.getEditorDescriptor(String) which allows you to get rid of the content type description and also of the reference to the text editor (see also bug 148993).
Created attachment 45464 [details] Patch with my changes applied
In addition I would add (or replace it by) the more flexible version of openEditor(...) which takes the following parameter(s): * @param activate * if <code>true</code> the editor will be activated and eventually: * @param determineContentType * attempt to resolve the content type for this file
Eric: I can't remember if I ever got back to you on this... essentially the compile error is fine, it's not a binary compatibility problem for plugins compiled against an older version. No need to re-export org.eclipse.core.filesystem. A similar problem came up in 3.2 with CopyFilesAndFoldersOperation. However, another option is to use URI in the API method instead (IDE.openEditor(URI)), and then use IFileStore under the covers... that's the approach I took in the org.eclipse.core.resources plugin.
Note that the changes to Bug 111887 will require a slight rework of the drag and drop portion of this patch
*** Bug 154686 has been marked as a duplicate of this bug. ***
Updateing the target milestone so it doesn't fall off my radar...
Deferring in favor of getting the Commands story done... Folks, this part of my cache has been over-written...what is the current state of this defect ?
Note that this is basically a dup of bug 13221.
Deferring until M6. Still need to determine what the 'slight rework' means...
*** This bug has been marked as a duplicate of bug 13221 ***
