Community
Participate
Working Groups
If I drag a view outside of the Eclipse main frame, Eclipse helpfully creates an independent top-level window to contain it. However, that window does not acquire a system menu, and so it cannot be maximized. I think this qualifies as a bug, since it's pretty nonstandard in addition to being inconvenient.
While in the neighborhood, I experienced some other oddities here. For example, I can't create a new external window by dragging an editor, but I can drag an editor into an external window created by dragging a view. The x-for-close button doesn't seem to be willing to do anything for me; the window persists until I drag the last tab out of it. One might imagine the x chasing all the tabs back to the main frame or closing them all.
There are a variety of issues that we're looking into regarding the 'Detached Window' support... *** This bug has been marked as a duplicate of 8886 ***
I would like to respectfull appeal the decision to glom this into 8886. 8886 carries a ton of freight: multiple editors and all kinds of very hard things. My initial report is a point bug in the functionality that is already present in the release plarform, so it seems not completely unreasonable to plead for a fix to it that isn't balled up 8886.
Reopen this defect to separate it from the faaar more difficult 'detached editor windows'.
I agree with this request, see also bug 121748 which requests not only doing a full system menu, minimize, and maximize, but also doing away with the internal CTabFolder tab when there is only one part in the window (as opposed to a stack of parts) and using what would have been the tab title as the window title.
See also Bug 123400 which has slightly wider requirements.
I think I'll make this an 'aggregate' defect (i.e. one that I'll use to track a variety of 'DW as Shell' issues. Accessibility demands a system menu (to move/close...) There's some argument about whether they should be 'top-level' shells so that platform window managers can be brought into play (that will require some sort of 'title') Others ?
*** Bug 121748 has been marked as a duplicate of this bug. ***
*** Bug 152893 has been marked as a duplicate of this bug. ***
*** Bug 160313 has been marked as a duplicate of this bug. ***
Hi Eric, Our RCP based product uses intensively the detached windows, and we are few days away from finalizing it. To workaround this bug I have patched the org.eclipse.ui.workbench plugin by modifying the function protected #void configureShell(Shell shell)# of the class WorkbenchWindow and instantiating the shells pool this way: detachedWindowShells = new ShellPool(null, /* To disable the on top behaviour */ shell.getStyle() /* to have a normal shell */ ); So far, our users were happy with the solution and didn't noticed side effects. Can you please tell me whatever I should deliver my customized org.eclipse.ui.workbench plugin or is there any other way that to avoid this solution? Many thanks
(In reply to Eric Moffatt from comment #7) > I think I'll make this an 'aggregate' defect Is this still the aggregation bug for detached windows?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
