[platform-ui-dev] Drag/drop refactoring

[Stefan Xenos <Stefan_Xenos@xxxxxxxxxx>]

I got tired of repeatedly fixing the
same drag/drop regressions, so I've cleaned up the drag/drop system (I'm
referring to drag/drop as it relates to repositioning views and editors).

I'm posting this in case anyone is trying
to figure out where the drag/drop code has gone.

Previously, most drag/drop code was
in PerspectivePresentation and EditorPresentation. Now, the most specific
object that manages the widgets for a region of the window also manages
drag/drop for that region.
- EditorArea handles dragging of editors
in the editor area.
- RootLayoutContainer handles dragging
of views in the workbench client area.
- TrimDropTarget handles dragging over
the border of the workbench window
- FastViewBar handles dragging of the
fast view icons
- EditorWorkbook handles dragging over
an editor's tabs
- PartTabFolder handles dragging over
a view's tabs
- FastViewPane initiates dragging from
an active fastview

PerspectivePresentation is still responsible
for detached views, but all other drag/drop operations have been split
up as described above.

The following types have been deleted:
IWorkbenchDropTarget, IWorkbenchDragDropPart, IWorkbenchDragSource. You'll
find the replacements in org.eclipse.ui.internal.dnd.

The general technique for locating drop
targets has also changed. Previously, data was attached to all the SWT
widgets to determine their position in the LayoutTree. Now, we are using
LayoutTree itself to do BSP searches based on the cursor position. The
major benefits are:
1. No more "no parking" icon
in the margins between views
2. The layout tree no longer requires
child objects to correctly ininitialize and attach data to their widgets
(which has been a common cause of bugs)

Hopefully this will be helpful to someone.
Cheers,

  - Stefan