Description Markus Keller 2012-11-02 14:48:55 EDT

Please bring back the 3.x mode of drag and drop for views and editors. The current implementation is not only ugly (green borders), but even worse, it's a nightmare from a usability point of view.


The basic problem is that drop target areas are not easily predictable and small mouse movements have a big effect. This is unnatural and should be avoided.

This bug is about rearranging views in the workbench window. Bug 387678 is a separate problem with drop feedback on view tabs.

The goal of drag and drop is that the user can quickly rearrange views. There are two basic operations:
- move a view to another views stack
- split an existing view stack into two and put the dropped view into the new part stack
(- corner case: split the whole window and insert the dropped view along an edge)

Move is cumbersome
------------------
"move" is the more common operation. A workspace layout typically stabilizes after an initial configuration phase. Then, views are moved around when the user opens a new view and doesn't like the placement, or when he needs to have two views visible to compare contents, feed input from one to the other, or drag items from one view to the other.

However, in 4.x, the "move" operation is cumbersome, since the drop area is now only the tiny tab bar. In 3.x, I could just drop to the center of the target view.

Unpredictable drop target areas
-------------------------------
In 3.x, the drop target areas were clearly defined:
- 0-25px from the edge of a view: split view stack and put dropped view to that edge
- more than 25px from the edge: put view into the view stack
(- outside of the views area: split window and put dropped view along the edge)

=> The only "flip regions" where a small movement of the mouse changes the drop operation are diagonal lines of length 25px*sqrt(2) from all corners. These are far away from typical drop regions, so they're not an issue in practice.


In 4.x, the drop operation seems to be influenced by many interfering factors:
- distance to a window edge
- distance to all four view edges

=> The view content area is full of flip regions. Even worse, these flip regions are in places where there's no guiding line or anything that could help the user find out where the operation will switch. Humans can easily target a spot close to a line (3.x), but it's much harder for us to
a) find a spot that is in the correct half of a large area, AND
b) is not too close to a window edge, AND
c) is closer to the correct edge than to one of the adjacent edges

E.g. start the SDK with a new workspace, and then try to place the Outline view below the Package Explorer. (Hint: the correct region is a tiny horizontal bar that is not delimited by anything and floats inside the view area).