Community
Participate
Working Groups
I really thought this was a great feature. In my case, I have a lot of screen real estate and found it useful to detach the object browser and task list. Out of curiousity, why was it taken out?
There were several problems with them. The most immediate problem was that they were inaccessible to keyboard users or those with disabilities. They did not get the accelerators for menu items from the main window. Also: You could not switch back to the main window using keyboard. It only worked on Windows (and even that was a hack). The context menu occasionally disappeared). We will not be adding this support back for 2.0, but will reconsider them post 2.0.
As a workaround you can choose Window / New Window and arrange the new perspective the way you want. You can also save your arrangement using Window / Save Perspective As...
*** Bug 15981 has been marked as a duplicate of this bug. ***
I submitted something similiar (Nick suggested I look at this), where you could have your editor windows at least in a separate (I suggest defaulting to all in one window, but you can also detach a particular editor 'tab'). I am not sure how the detached views were originally implemented, but if you could make it so they are SDI windows that you can, on Windows, ALT-TAB between, that would be great for keyboard users ... certainly does get a bit more complicated to manage them when the current system supports multiple perspective windows (ie double click to open, does it open in the perspective, existing external editor...probably best to associate the 'editor tab control/window' to a given perspective, so if it is dragged out, you could know where the editor windows shoudl be opened into) In terms of folks with disabilities, if they aren't going to detach, then it should never be an issue, as long as you assume attached first. Sorry just rambling out loud. Mine feature request was number 20529, for those that are curious. FYI: I love Eclipse, been quite happy with it since I started using it three days ago.
To clarify the accessibility requirements, any feature we provide must be accessible to those with disabilities. For more on this interesting area, click on Guidelines at http://www- 3.ibm.com/able/. However, accessibility was not the only reason for removing detached views. Note that you can get an editor in a new window by opening a Java perspective, closing all views, saving this perspective under a new name ("Java Editor"), then opening it in a new window and using Navigate / Open Type... (or Ctrl+Shift+T) to open a type in the new perspective.
*** Bug 21802 has been marked as a duplicate of this bug. ***
Reopen to investigate
*** Bug 12841 has been marked as a duplicate of this bug. ***
Will not be in 2.1. Consider for 2.2
When working on this PR, please review the following related PR: [View Mgmt] View Locks To Prevent Views from being Moved http://bugs.eclipse.org/bugs/show_bug.cgi?id=14369
*** Bug 43325 has been marked as a duplicate of this bug. ***
Isn't this bug duplicated with https://bugs.eclipse.org/bugs/show_bug.cgi?id=19725 (proposing floating windows : editors/views, instead of only views ?)
*** Bug 19725 has been marked as a duplicate of this bug. ***
Yes, bug 19725 is a dup of this one, with the added request to support detached editors.
Here is a quick summary of the state of affairs with detached views: In recent builds, you can turn the Workbench support for detached views back on by passing -detach on the command line. However, this is currently broken. Apparently the SWT call Control.isReparentable() is returning false where it used to return true on Windows. This should be discussed with the SWT team. Note that using reparenting is preferable to disposing and recreating the view, since there may be interesting widget state that is not captured by the view's saveState method. For example, the Navigator saves the top-level expanded elements, but not expanded elements under collapsed elements. Many views save the selection, but not the scroll position. On shutdown/restart, it's acceptable to just restore the selection and make it visible, without the scroll position being exactly the same as before, but when rearranging views users don't expect state like the scroll position to change. Having the view's saveState method capture more state to support detached views is not a good answer. For example, the Navigator used to save the complete expanded state (including the state for hidden elements), but that turned out to cause a major performance hit on startup and also for popping up the context menu (believe it or not, since Tree.getSelection() in SWT is O(N) in the number of items in the tree). There may also be UI state that is not possible to capture and restore on the widget via API. Even when SWT control reparenting works, detached views have the following defects: 1. Once detached, dragging the titlebar to move the detached window does not work. This is apparently a regression in the DnD support in the Workbench (we need to use DnD since the titlebar is not a regular window titlebar, it's a view titlebar). Compare with R1.0. 2. In the following scenario, context menus stop working: - detach a view - restart Eclipse - drag the view back to dock it in the main window This is due to menus in SWT being associated with the shell rather than the control passed to the Menu constructor (unlike regular controls). So when the detached window's shell is disposed, the menu gets disposed with it. The SWT team was investigating a solution to this, but I'm not sure what the status is. 3. Accelerator keys (and the keybinding story) don't work on detached views. This is one of the main reasons we backed away from detached views for 2.0 (see above). Previously the only way to get accelerators was via menu items. Since detached views don't have their own menubar, accelerators were not possible. Now that keybindings are implemented using the new SWT support for filtering events, we should be able to make them work in secondary windows like detached views (preference pages and wizards would be nice too). Should coordinate with Chris and Doug on this. In addition to the above defects, there are some usability problems with detached views: a) DnD is overloaded, being used for detaching the view, moving it around while detached, and redocking it. In the current implementation, it's not possible to reposition a detached view over the main window without it being redocked. I see two possible approaches to this: i) Reduce the overloading, e.g. use DnD only for repositioning, and have explicit titlebar context menu actions for detaching/docking views. ii) Refine the DnD support to have more specific areas for redocking, so that dragging a detached view over most areas of a main window repositions the view rather than redocking it. This approach requires strong cues to communicate what the result will be (e.g. cursor changes and/or highlighting the destination area in the main window). b. Detached views currently always appear in front of the main window. On single monitor systems with Eclipse running maximized, this really restricts the usefulness of detached views. Approaches here could include: an easy way to temporarily hide detached views, allowing detached views to be stacked under the main window (should they appear in the task tray?), transparency. In the short term, we should get detached views working as they were before: - coordinate with the SWT team on why isReparentable() is returning false on Windows - fix up DnD for repositioning detached views This will at least make detached views usable on Windows. We can then focus on fixing the remaining defects, and experimenting with different approaches to the usability problems.
I am partway through a fix for this. My plan is as follows: The new implementation will try to use SWT's reparenting if available, but will fall back to destroying and recreating views if this is impossible. This will allow the feature to work on all platforms, even if the scroll position changes on some platforms. Use of SWT's reparenting will be temporarily disabled for the first version to ensure that the "destroy-and-recreate" approach is well tested. I have started working on a fix for 1). Haven't examined 2 or 3 yet. I think we should fix them before enabling this feature by default. Issues a) and b) could probably wait until later. Just for consideration, we might want to try this: rather than treating undocked windows as part of the current perspective, we could actually create a new workbench window for the new view (one that only contains the view). This would seem to solve a lot of problems: - The window would not rely on DnD support for movement, fixing 1. - Keyboard users could alt-tab to the undocked window. - The undocked window would have its own menubar, allowing keyboard accelerators to work (fixing 2) - The undocked window could be moved and dragged on top of the main Eclipse window without docking. Dragging the view would dock it back to the main Eclipse window, and dragging the window would allow it to be repositioned. - Unwanted windows that appeared on top of the Eclipse window could easily be minimized using the OS's native facilities. I'm just offering this for discussion -- this is not the approach I'm taking right now.
Here's why undockable windows stopped working: We made the faulty assumption that SWT reparenting either worked or didn't work for all controls on the windowing system. In the latest SWT, they've removed reparenting for Shells, and the widget we test to determine our reparenting policy is a Shell. Since we don't need to reparent Shells anyway, this isn't a problem for us. Due to the urgency here, I'll attach a fix that brings the code up to a state similar to what it was before... but I am certain that there will be serious bugs for platforms that don't support reparenting.
Created attachment 6703 [details] This should bring floating views back This patch will not fix any problems -- it just brings back detached views in exactly the same state they were in before they disappeared.
Created attachment 6705 [details] Same as above I selected the wrong content type above.
The patch has been applied to the head. Remember, this patch does not fix any problems with the original detachable views code. This only moves the check for detachable to a bogus composite.
1) The isReparentable() returning false in Shell is a bug fix in SWT. Shells are not reparentable on Windows. You should be asking whether the widget you are about to reparent is reparentable, not a "bogus composite". 2) The context menus (and other internal SWT things) should be getting fixed up when the reparenting occurs. The context menu moves over with the composite and gets reparented to be in the new shell. 3) The key binding story should work in dialogs. We are fixing bugs as they are reported.
See also bug 46565 (dragging editors between windows).
Created attachment 7539 [details] Fixes window dragging, and adds maximizing, and minimizing This is a patch for DetachedWindow in the new_look stream. It enables the OS-native title bar and trim, allowing windows to be dragged, maximized, and minimized. This isn't as pretty as before, but it is much more useful.
Note that this should be revisited again once the appearance and behavior of detached views is finalized for 3.0.
Stefan, does your patch address points 1,2,3 in comment #15?
Created attachment 7556 [details] Prettier alternative without the OS native trim This is an alternative patch for detached windows. This patch fixes some of the problems with drag-and-drop, and lets you move around detached windows without enabling the OS trim. This is much prettier than the previous patch, but it does not provide any way to drag a detached window on top of the main workbench window without docking. This patch was created against the org.eclipse.ui.workbench project in the new_look stream at 8:00pm on Saturday Jan 24th. Both this patch and the previous one address the window dragging bugs. Neither patch addresses the problems with context menus or hotkeys, however I cannot reproduce either problem in the new_look stream, so it is likely that both issues were fixed by other bugfixes.
Chris, can you commit the patch in comment 26?
*** Bug 50311 has been marked as a duplicate of this bug. ***
Patch released.
What about the patch in comment #23? I like Stefan's proposed solution in comment #16. Is it possible? I'm not entering a new bug report because it is related to this one so I just like to reference bug #37997 comment #131.
Isn't is possible to support tear off views on all platforms if we go another way of implementation and create non blocking child windows for tear off views (like for dialogs)? These windows would conatain another tab folder and multiple views can be dragged an dropped into them. This would also allowus to place and move the views all over the workbench or to other monitors without having to watch the mouse cursor every time such a view is moved. I don't like the current behavior because it is somewhat uncommon for me as I never had an application with a similar behavior. Most apps behave like multiple window apps. Of curse this requires another button for docking the view back into the workbench but this could be also implemented using drag and drop again (the window can be moved the regular way and the view can be dragged when clicking its tab. IMHO if an environment doesn't support reparenting some necessary elements we can even close and reopen the view in the new window. This is ok when we document this in a views API. If a view doesn't save and restore its state correctly and this is a bug of the specific and should not prevent other clients from using this feature. In an extreme case it might be even possible to force views to overwrite a specific API like "supportsUndockable" (which returns false by default) although I would not like it ;).
Yes , I think it is a needed feature. As former smalltalker, I've always found that the ability to detache views form the workench and to put them wherever I want (or even iconify them separatly) is very useful for an experimented user... regards Xavier
fixed for supported platforms
*** Bug 40599 has been marked as a duplicate of this bug. ***
It seems a while since anyone looked at this issue - Any chance of getting this added again in the future?
Beirti, detached views -were- added back in 3.0, on platforms that support widget reparenting, and this bug has been RESOLVED/FIXED since then. If there's an outstanding issue for you, please file a separate bug.
(In reply to comment #36) > Beirti, detached views -were- added back in 3.0, on platforms that support > widget reparenting, and this bug has been RESOLVED/FIXED since then. If > there's an outstanding issue for you, please file a separate bug. > My mistake, I confused this bug with the desire for detaching an Editor.
