Community
Participate
Working Groups
When a file is dragged from the Navigator view and dropped in an editor on Solaris, it is first deleted from the workspace then the workbench attempts to open the file withing an editor. This attempt is unsuccessful since the file has been deleted.
This sounds pretty serious. Any chance this is being done by the Navigator or Workbench, or does it look like free OS behaviour?
In windows XP when you drag a file into the editor area its treated as a drag copy. You can tell because the + icon appears next to the cursor when the cursor is in the editor. On Solaris, it seems like the drag is being treated as a move rather than a copy.
Jeff, when you drag within the Navigator, does it default to a move or a copy? Which build are you using? This works for me on Linux Motif, build RC2. Likely a SWT problem.
I'm using build RC2. When draggin within the Navigator, it defaults to move.
Sounds like drag is incorrectly defaulting to move on Solaris. Moving to SWT to investigate.
*** Bug 35721 has been marked as a duplicate of this bug. ***
Marking as critical since bug 35721 was marked critical. The EditorAreaDropAdapter sets the operation to DROP_COPY in dragOver. In addition to the Ctrl key workaround I mention in bug 35721 you can also restore the deleted file using the "restore from local history" action.
Should add this problem and workaround to readme.
Created attachment 4388 [details] Possible workaround, EditorAreaDropAdapter.class Please try out the attached workaround and let me know if it works 1. copy the class file EditorAreaDropAdapter.class into the (new) directory bin/org/eclipse/ui/internal in the org.eclipse.ui.workbench_2.1.0 plugin directory. 2. start eclipse with the additional parameter -dev bin The change is to set the drag operation in dragEnter, not dragOver (changed the method name).
To confirm, I don't see this problem on linux-motif.
Jeff and Grant tried to reproduce thus problem on the sunblade machine in the SWT lab. The file was copied and not moved. It looks like this a problem only on older versions of Solrais. Jeff to update this bug report with the version of libXm.so installed in the UI lab.
Created attachment 4396 [details] EditorAreaDropAdapter$1.class You may need to also put this inner class together with the patched class in the bin directory.
Created attachment 4397 [details] EditorAreaDropAdapter.java Patched source file Tod requested for self hosting. It would still be good to know if this fixes the problem, even if it only occurs in older versions of Solaris.
Here is the readme item which Jim wrote, which we decided not to include in the 2.1 readme, since the problem was only seen on an older version of Motif. Dragging file to workbench editor deletes file (Solaris Motif only) On Solaris, dragging a file from the Navigator view and dropping it in an editor deletes the file. The workaround is to hold down the Ctrl key while dragging, or use the Open command (or double click) to edit the file. Use the Restore from Local History command in the Navigator context menu to restore the deleted file. (bug 34648)
Tried with the attached EditorAreaDropAdapter.java file. Seems to fix the problem. I was no longer able to reproduce it.
Released the change to EditorAreaDropAdapter. Would still be desirable to get this fixed/worked around in SWT since other DropTargetListeners may be affected. Leaving readme keyword since this would be a SWT readme item if it's not fixed.
There is a bug in the DropTarget on motif - it should only allow operations defined in the style of the DropTarget. This is fixed in 3.0 and I can patch a simple implementation of this into 2.1.1 and I should do it on all platforms. With the fix, you will not be able to drop items on the editor area (but at least it will not delete your file). The editor area problem is addressed in the following bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=37596
I have found the real reason for the problem: The Solaris box we are testing on is so slow that you can drag the file into the editor area and drop it and the events you get are DragEnter, DragLeave, DropAccept, Drop. There is no DragOver event. Since the EditorAreaDropAdapter just sets the event.detail to DND.DROP_COPY on DragOver, the operation remains DND.DROP_MOVE and the file gets moved. There are two possible fixes: 1) In SWT, do not allow an operation that the drop target has not specified in its style (this is already implemented in 3.0). 2) The EditorAreaDropAdapter should set the event.detail to DND.DROP_COPY on DragEnter and DragOperationChanged. For 2.1.1: If I implement solution 1, it should be done on all platforms (because you could have this scenario anywhere not just Solaris) and the user will not be able to drop files on the EditorArea. If Knut changes the EditorAreaDropAdapter, you will still be able to drop files on the EditorArea and it will be fixed for all platforms. I recommend we go with the second solution.
Should just fix EditorAreaDropAdapter for 2.1.1. This is the lowest risk fix. For 3.0 it looks like you already released changes. I have to add DROP_COPY to the EditorArea drop target in order for drop to work.
Opened bug 37691 for 2.1.1 action.
Closing this bug report. In 2.1.1 the neccessary work is tracked by bug 37691. In 3.0, the DropTarget has already been modified to not allow this case and additional changes required by EditorAreaDropAdapter are addressed by bug 37596.
