Community
Participate
Working Groups
In the Resource or Java perspectives, after dragging an html file from the navigator to be viewed in Mozilla, the file is deleted from the Eclipse views and from the filesystem. Not true of IE 5.5 or Netscape 4.72 on the same machine. Versions: - Eclipse 2.0.2 - NT 4.0 SP6 - Mozilla 1.2.1
Not SWT.
Mozilla returns DRAG_MOVE feedback to Eclipse when the drop has occurred. This means that the target accepted the dragged data and the source should remove it. Notice that Netscape displays drag feedback for a move operation also during the drag. However, it returns DRAG_NONE when the file is dropped. The result is that Eclipse does nothing with the drag source. If you hold down Ctrl while dragging, Mozilla indicates a copy (which is also not quite right but at least it doesn't delete the drag source). There's nothing I can do, short of removing our drag move feature, if Mozilla insists that it wants to move the file. You should open a bug against Mozilla. Copying Veronika to make sure I'm not missing anything.
I will install Mozilla and have a look. Are you sure it is not doing a DROP_TARGET_MOVE? /** * Drag and Drop Operation: the drop target moves the data and the drag source removes * any references to the data and updates its display. This is not available on all platforms * and is only used when a non-SWT application is the drop target. In this case, the SWT * drag source is informed in the dragFinished event that the drop target has moved the data. * (value is 1 << 3). * * @see DragSourceListener#dragFinished */ public final static int DROP_TARGET_MOVE = 1 << 3;
submitted to http://bugzilla.mozilla.org/show_bug.cgi?id=191400
No DROP_TARGET_MOVE, I stepped through the code.
Veronika, is it possible to limit drag operations outside Eclipse to copy? The navigator drag source specifies copy and move operations. We would like to either a) default to copy when dragging outside Eclipse or b) only allow copy when dragging outside Eclipse When dragging within Eclipse we still want to allow move and if possible default to move. a: I don't see a way to default to copy since the drop target has sole control over this. b: Since there can only be one drag source per control I also can't just specify DROP_COPY for the FileTransferType and DROP_COPY | DROP_MOVE for all other transfer types. The drag source seems to be very limited in the control it has over the drag operation.
It is not possible to know whether the drop target is internal to the application or external and it is not possible to specify alternate behaviour for internal versus external drop targets.
So the only thing we can do is note the transfer type that was requested in dragSetData and ignore the DROP_MOVE operation in dragFinished if the last dragSetData was a FileTransferType. The net result is that we would only allow copy when dragging outside Eclipse. We would still indicate a move. This seems to be what Visual Studio is doing. When I drag from VS to Mozilla it indicates a move, when I drop the file remains in Visual Studio. It's not great but it's better than deleting data.
I looked into the JDT/UI code and disabling move can be done. However when users move files to the desktop or the windows explorer a move is performed since in this case the target handles the move indicated by a DND.DROP_TARGET_MOVE. Disabling correct handling of move for other application will IMO lead to a even bigger user confusion since sometime we will copy and sometimes we will move. Since the problem seems to exist only for a special Mozialla version (Netscape 6.2.1 and Netscape 7.01 are fine) I opt to do nothing.
I released a fix for the resource navigator like I outlined above just before you wrote your comment. I agree that this fix/workaround is suboptimal since we cannot always prevent a move. We can only do so when it's a DROP_MOVE and not a DROP_TARGET_MOVE. However, the DROP_MOVE is the destructive case. Since we are dealing with a data loss scenario here I would prefer to put in the workaround. If we get complaints that a move does a copy we can take it out. Chances are that nobody intentionally drag moves from Eclipse. Veronika, when I drag from Visual Studio to the Windows Explorer the operation defaults to a copy. When I drag move from Eclipse it defaults to a move. There must be some way that Visual Studio tells Windows to default to copy. How does the Explorer know that the drag should not be a move? This is on WinNT, BTW.
I disabled move. But I still think we shouldn't do this since we disable a useful function due to a bug in another programm. I doubt that Mozilla would fix an Eclipse bug ;-)).
I entered bug 32409 to track the drag move issue and revisit this. I'm on the cc list for the Mozilla bug. When that is fixed we can remove our workaround and hope that no other applications have the same bug. Ideally we would do something to consistently prevent drag moves out of Eclipse. See the bug for details.
