Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #156323 +++ Dragging selected text in editor This feature is now available in the Eclipse Platform. Please, please, please add this feature to PDT!
StructuredTextEditor override method: protected void installTextDragAndDrop(ISourceViewer viewer) { // do nothing } What is the reason?
(In reply to comment #1) > StructuredTextEditor override method: > protected void installTextDragAndDrop(ISourceViewer viewer) { > // do nothing > } > What is the reason? Extension points we've had since before WTP 1.0 have allowed drop handlers to be registered and changed on the fly, conflicting with the newly introduced IDragAndDropService (see bug 173405, bug 173410, and bug 178104) and its support in AbstractTextEditor. Dropping text into the editor already works through StructuredTextEditor.initializeDrop(ITextViewer)
*** Bug 283994 has been marked as a duplicate of this bug. ***
You should also be able to hold down ctrl while dragging to copy the selected text once this bug is fixed, right?
Please fix Drag and Drop text in Eclipse for PHP, HTML, CSS, XML (source view) etc. Thanks! John
we still don't seem to have drag and drop in HTML, XML, JSP, or CSS, this would be nice to have but seems like an enhancement request not a bug fix.
"we still don't seem to have drag and drop in HTML, XML, JSP, or CSS, this would be nice to have but seems like an enhancement request not a bug fix." I would deem this a bug. If it was totally unavailable I would consider it a "feature request". However, the fact that I can highlight and drag text in a file with the extension .js, but not in a file with the extension .htm presses me to label this a bug. Especially as HTML is probably the most ubiquitous language out there. Please address in a future update. Thank you. My file extension should not determine my text editing features.
*** Bug 387549 has been marked as a duplicate of this bug. ***
Mmm, this bug is 7 years old, and marked as P2... As I routinely drag'n'drop snippets of code, to move them or to copy them (and change them thereafter), I see this bug in the Web Tools to be a major drag (erm). I dislike using the clipboard when I can avoid it, as I prefer avoiding polluting my clipboard manager history, and beside, I find its usage slower for such small movements. Of course, I don't see the difficulties in fixing this (lot of legacy code to update?), but I sure hope somebody will have a look at it. Thanks.
Created attachment 255936 [details] A screen shot to illustrate how to patch MergeDropTarget inner class Patch the code change in EditorSiteDragAndDropServceImpl
(In reply to Jack Chi from comment #10) > Created attachment 255936 [details] > A screen shot to illustrate how to patch MergeDropTarget inner class > > Patch the code change in EditorSiteDragAndDropServceImpl I also think this bug should be assigned to platform team. this problem is found in the ui.workbench project so it has nothing to do with web standard tool project. The platform team is still actively working on e4 projects so there should be some developers there to own this project.
Created attachment 255937 [details] Patch file Provide this patch file so that you build a new ui.workbench project and put the produced jar file in your target folder.
I found some code in IDEWorkbenchWindowAdvisor.preWindowOpen() that shows you how to set up the drag and drop in your workbench. Ignore my previous patch and comments. configurer.addEditorAreaTransfer(EditorInputTransfer.getInstance()); configurer.addEditorAreaTransfer(ResourceTransfer.getInstance()); configurer.addEditorAreaTransfer(FileTransfer.getInstance()); configurer.addEditorAreaTransfer(MarkerTransfer.getInstance()); configurer.configureEditorAreaDropListener(new EditorAreaDropAdapter( configurer.getWindow()));
How can I help?
(In reply to Dawid Pakula from comment #14) > How can I help? Comment 2 sort of explains the state of things--because our older extension point allows for *removing* drop listeners as well as adding them, an ideal design would somehow avoild losing that ability, and a solution hasn't been thought up, yet. It's likely that being able to cleanly remove drop listeners isn't a useful trait any more, but the code to support the existing internal extension point on top of the Platform's would still need to be written. I'm not keen on breaking the existing editors that hook in that way to use the StructuredTextEditor as their source page.
(In reply to Nitin Dahyabhai from comment #15) > (In reply to Dawid Pakula from comment #14) > > How can I help? > > Comment 2 sort of explains the state of things--because our older extension > point allows for *removing* drop listeners as well as adding them, an ideal > design would somehow avoild losing that ability, and a solution hasn't been > thought up, yet. It's likely that being able to cleanly remove drop > listeners isn't a useful trait any more, but the code to support the > existing internal extension point on top of the Platform's would still need > to be written. I'm not keen on breaking the existing editors that hook in > that way to use the StructuredTextEditor as their source page. I'm not sure how drop listeners can be removed? As I see StructuredTextEditor on startup register own drop adapter and read possible transfers via ExtendedEditorDropTargetAdapter.
New Gerrit change created: https://git.eclipse.org/r/155409
(In reply to Dawid Pakula from comment #16) > I'm not sure how drop listeners can be removed? I might have been thinking of it as one of the features that could be reconfigured when the editor's input changes, but it doesn't seem to be wired up to do so. If our own text drop listener is still handling text drops when merged into the platform support, it could mimic what the platform does by remembering the previously selected text on a drag and removing it when dropping text (and forgetting about it afterward). That's the bulk of what users would care about, I suspect.
I prepared working solution on Gerrit. SSE IDropAction works like before and if IDropAction isn't configured for TextTransfer, AbstractTextEditor implementation will be used
Gerrit change https://git.eclipse.org/r/155409 was merged to [master]. Commit: http://git.eclipse.org/c/sourceediting/webtools.sourceediting.git/commit/?id=f780b8a7ac93ad53785359fe6ab0617e34724b07
I think this also resolve: bug 173405
Amended with one more commit to restore and incorporate a protected method we'll have to keep. Thanks for the push on this one, Dawid.
I also created bug 558947 on Platform. After resolve we will be able to drop DefaultTextTransferDropTargetAdapterProxy
