Community
Participate
Working Groups
Build Identifier: M20100909-0800 The bug can be reproduced using GEF's logic example. Create a diagram with a few dozens labels so that a scrollbar appears. Try to drag to move the first item to the end using drag & drop. The view will scroll down correctly but when dropped the item is positioned at the wrong index. It looks like the new index doesn't take in account that the view was scrolled down. On Mac OS X Cocoa the behavior the reordering doesn't work at all. The view scrolls down but the cursor changes into "drop denied". Perhaps this is a different bug. Reproducible: Always
After additional debugging I can see that TreeContainerEditPolicy#findIndexOfTreeItemAt returns the correct index while dragging the item. However, once dropped the tree scrolls back and the last call to findIndexOfTreeItemAt returns the index without taking scroll into account.
There is also another annoying issue. When dragging an item outside of the tree bounds the scroll jumps back to its original position. This can be very annoying since the user must take care to keep the mouse cursor inside tree bounds otherwise it has to start from the beginning. This is not how drag & drop behaves in other Eclipse views like Project Explorer or Outline View for a Java file.
(In reply to comment #1) > After additional debugging I can see that > TreeContainerEditPolicy#findIndexOfTreeItemAt returns the correct index while > dragging the item. However, once dropped the tree scrolls back and the last > call to findIndexOfTreeItemAt returns the index without taking scroll into > account. I debugged into this as well and found out that the computation of the wrong index is a side-effect of restoring the old selection within eraseDropFeedback (the viewer scrolls back).
Created attachment 185505 [details] Removed performing and restoring of selection in show/eraseDropFeedback Actually, I am not quite sure, why the code to select an item when showing feedback and restoring the old selection afterwards actually is in place. The cvs history of TreeContainerEditPolicy does not give any guidance, the code seems to have been in place right from the beginning. On Windows XP the behavior is quite correct without it, so I assume SWT has changed some behavior since the inception of the code. The problem on MacOSX Cocoa seems to be caused by another (additional) problem I will have to investigate further. Peter, could you try the following patch on Carbon and see if it is working there without the perfoming/restoring of selection as well?
(In reply to comment #4) > Created an attachment (id=185505) [details] > Removed performing and restoring of selection in show/eraseDropFeedback > > Actually, I am not quite sure, why the code to select an item when showing > feedback and restoring the old selection afterwards actually is in place. The > cvs history of TreeContainerEditPolicy does not give any guidance, the code > seems to have been in place right from the beginning. > > On Windows XP the behavior is quite correct without it, so I assume SWT has > changed some behavior since the inception of the code. The problem on MacOSX > Cocoa seems to be caused by another (additional) problem I will have to > investigate further. Peter, could you try the following patch on Carbon and see > if it is working there without the perfoming/restoring of selection as well? The problem on Cocoa seems to be caused by the fact that - in difference to Windows XP - the TreeViewerTransferDropListener does not receive any dragOver events when the mouse cursor is moved into the area that was invisible before. It seems to be an SWT problem though and I will try to isolate it and report it in a different bug.
I tested the patch with Eclipse 3.6.1 for Carbon and the index calculation works correctly now. The scroll does not jump back when the mouse quits the bounds of the tree. However I quite quickly got a crash that I reported in Bug 332808.
Created attachment 185515 [details] Monkey patch to be added to the subclass of TreeContainerEditPolicy Alexander, I retrofitted your patch into something that can be applied at runtime in current versions. I call it monkey patching :) Perhaps others will find it useful.
(In reply to comment #6) > I tested the patch with Eclipse 3.6.1 for Carbon and the index calculation > works correctly now. The scroll does not jump back when the mouse quits the > bounds of the tree. However I quite quickly got a crash that I reported in Bug > 332808. Verified that with the patch, index calculation also works on linux GTK x86_64 (Ubuntu 10.04 LTS).
Committed patch to 3.6 maintenance branch and HEAD.
Raised separate bug to keep track of Cocoa related problems (we already have separate bugs for the Carbon related issues). Closing this as resolved in 3.6.2.
(In reply to comment #10) > Raised separate bug to keep track of Cocoa related problems (we already have > separate bugs for the Carbon related issues). Closing this as resolved in > 3.6.2. ... which is bug #332956 of course.
