Community
Participate
Working Groups
DND should be a shortcut to refactoring. But by default most drag operations among JDT views perform a copy. This is counter-intuitive and is bad coding practice. First, it doesn't make sense to copy methods, fields, or inner classes. Move (which is a refactor) is a more common operation. If I am using the same member in two places, I should refactor it to a location where I can access it from both locations. Copying means I have to maintain the same code twice. Second, holding Control to indicate copy is more widespread than holding Shift to indicate don't copy. Third, if the user assumed a move occurred, but it was actually copy, it is unlikely to cause a compile error, and the user might not realize a copy happened. But, if the user assumed a copy occured when a move actually occurred, this will often introduce a compile error, alerting the user. In my opinion, a default of Copy was chosen because limited refactoring support at the time meant that Copy would be enabled more often than Move. For example, moving a nested Type into the package as a top-level Type. I think 2.1 supports more Moves. If nothing else, allow the default operation to be changed via preference.
Yes, the reason for defaulting to copy was that there aren't many Java elements for which we support a move refactoring. Since that now more move refactorings are in place we should check if we can change the default behavior. But in general our implementation is consistent with others since is gives the right feedback for the default behavior. If it is copy the DnD cursor has that little + sign on Windows. DnD a file inside the Windows Explorer to a different drive. In this case the default is copy and you have to press a modifier to perform a move operation. Adam, please check if we could now default to move for some of our DnD operations on Java elements.
But, if the drag is to another folder on the *same* drive, it is a move. I think we should consider java Types to be folders, not drives. We could say that projects are "drives", and therefore copy is the default, but I find the Windows behavior to be annoying sometimes. And, a single hierarchy of classes may span mulitple projects, and the User can't really see this.
there're a couple of more 'moves' possible but not implemented by dnd now: a. static members b. members types to top level c. pull up (kind of a move too) i see this report as a request to make these dnd enabled (with a question on drop 'do you want to simple textual move or the other more fancy thing?') would that a valid assesment?
No, actually the request is that the transferdroptargetlistener not set the DropTargetEvent's detail field to DND.DROP_COPY. I think refactoring is more common than duplicating the same method in multiple places. And even if it isn't, DND is usually a move until CONTROL is held down.
nothing planned for 2.1
closing - no plans to change the current behavior
.
*** This bug has been marked as a duplicate of bug 19807 ***
