Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 52252

Summary: [DetachedViews] [EditorMgmt] add ability to tear off java editors
Product: [Eclipse Project] Platform Reporter: Christophe Cornu <christophe.cornu+eclipse>
Component: UIAssignee: Stefan Xenos <sxenos>
Status: RESOLVED DUPLICATE QA Contact:
Severity: enhancement    
Priority: P3 CC: ed.burnette, matthijs.wensveen, nikolaymetchev
Version: 3.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Christophe Cornu CLA 2004-02-17 10:18:12 EST 
I20040217 new look

It is possible to tear off the navigator view into its own separate window. 

Could this feature be generalized to java editors as well?

This would serve the following use case:
- a configuration with 2 monitors, Eclipse on the left monitor
- tear off 1 java file and set it on the right monitor.
- edit java files inside the Eclipse workbench on the left monitor, while 
having the content of the java file on the right monitor always visible.

The current workaround is to do a new window and move the second Eclipse to 
the right monitor - with some space still used by the coolbar, and more clicks 
to achieve a similar result.
Comment 1 Matthijs Wensveen CLA 2004-08-02 21:08:20 EDT 
The editors seem to behave very different as compared to the rest of the
windows/panes. When no editor is open, there is still an empty space reserved
for it. This makes the workaround less usefull when you want no editor on the
left side and the rest of the editors on the right monitor in a separate window.
One problem that needs to be solved, I think, is wheter every editor is allowed
to detached, or just the whole editors pane.
Comment 2 Ed Burnette CLA 2004-09-24 09:24:43 EDT 
I wrote an RCP application that used an editor part for a web browser window 
and a view part for the favorites list. It was unnatural not to be able to 
tear that off the browser window just like the favorites. And yet using an 
editor was otherwise a natural for a web browser since what is a web page but 
a document? I suspect that some people are using mult-instance views where 
editors would be more natural just because of the editor part restrictions.

I suggest that both individual editor parts and editor stacks be tear-offable 
and re-dockable pretty much like views. But I think it's ok to preserve the 
one-editor-stack-per-page restriction for now. (I'll save the request for fast-
editors for later but keep that in mind :)

And no, I don't want to write my own presentation for this. Been there, done 
that, got the hat.
Comment 3 Stefan Xenos CLA 2004-09-24 17:15:05 EDT 
No worries, Ed. The presentation API is intended for cosmetic stuff (like
placement/appearance of tabs, buttons, toolbars, etc.). If we added tear-off
editors, it would be a workbench feature and would not need to be re-implemented
in every presentation.
Comment 4 Douglas Pollock CLA 2004-09-28 12:06:53 EDT 

*** This bug has been marked as a duplicate of 8886 ***