Community
Participate
Working Groups
There doesn't seem to be an intuitive way to drag a detached view so that it floats on top of an area where it could also be docked -- the workbench insists on always docking it whenever possible. Using the Resource perspective as an example, if I detach the Navigator view and try to drag it and float it over the editor area, the workbench will always snap the view to one of the edges of the editor and force it to dock. The only way around this is to drag the view a bit at a time, always keeping the mouse within the bounds of the detached view (so that it never senses a dockable area), but progressively moving closer to the area where you want the view to be positioned. Proposed solution: Visual Studio and MFC apps that have docking functionality use the Ctrl key to force the view to remain floating when it's being dragged. That is, if I hold down Ctrl while I'm moving the view, the main window will never try to dock it, regardless of whether the mouse is over an area where it would be possible. Similar functionality should be trivial to implement in the Eclipse workbench. If this Ctrl+drag paradigm doesn't conflict with existing behavior in other window managers, then this would be a solution that conforms to the expected behavior of many other applications already available.
Not possible to check modifier keys in a tracker event loop. However, I've just added this feature through another mechanism. *** This bug has been marked as a duplicate of 58003 ***
