Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-ui-dev] Drag/drop refactoring

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

Back to the top