Community
Participate
Working Groups
My build number: 20020125 Users coming from VisualAge are probably missing the freedom to open & arrange their editor windows independently from the workbench (so am I). Would be great to undock editor windows as you can undock any of the view windows. Or even better: To open eclipse editor windows as you can open external editor windows (which do not support OLE) from eclipse. E.g. In eclipse I have associated *.properties files to the external program "Textpad" (does not support OLE). If I doubleclick on a properties-file in the tree, a seperate Textpad window opens outside of eclipse. Would be nice if you could open an eclipse editor window the same way. Maybe through context menu "open in floating window" when clicking on a file in the tree. And maybe even this in combination with the feature request "Multiple view on one file" (Bug 8871)? -> Opening through context menu "open in new floating window" when clicking on a method in the tree. Oh oh, so many requests... But I'm sure, ex-VisualAge-users would really happy about this. Chily :o) "Simon Arsenault" <simon_arsenault@stop.oti.com> wrote in Newsgroups: eclipse.tools Something to consider - what would you do with the views that complement the editor (like the outline view, hieararchy view, etc)? Should they also be included when opening the editor in a new window? How is the workbench to know which views to bring along, if any? I guess the better question is in what situations would opening editor in a new window be useful to you (i.e what task/use case do you see yourself using this feature)? Could it be done another way? Is the feature to compensate for a limitation in the workbench? Note, please do not take the previous paragraph as an indication we do not want to implement this feature...to the contrary, we are looking to understand the problem and use cases for the feature just to be sure another solution might be more appropriate. Your request for opening more than one editor on the same file in the same window is interesting. Please open a separate feature request. Would allowing the editor to have "split views" inside it solve the same problem? Opening it in a separate window ok too? Which one would work best for you and why? Each solution has some interesting usability issues. For example, opening the same file in multiple editors in the same window - when I double click on the file in the navigator view, which editor is activated? (again, this is not to indicate we do not want to implement this feature, its just to show that there are interesting issues to be addressed) Simon :-) Chily wrote: I personally would prefer to have no extra views attached to a floating editor window. Use the docked workbench views for navigation instead. My usual way of working with VAJ was to browse through the packages in one (docked) view (similar to the packages view in eclipse), select a class in the (docked) single-package-view (similar to the hierarchy view in eclipse when package "opened in type hierarchy") and double-click a method in the (docked) single-class-view (similar to the hierarchy subview in eclipse). This opened another workbench-independend window showing just this one method. So I could edit/compare many methods at the same time, even in combination with other programs. This way, I used the workbench just for navigating and other functions. And I often minimized it when editing files. So I didn't waste screen space for the navigation. I could imagine, leaving the whole window handling to the operating system in this way would also save a lot of work for the eclipse programmers. I think, independend windows always give the most freedom to the user. And with independend windows you can give every window the best size (fitting to its content), and have the best use in combination with other programs without wasting space for views you just need every now and then. About "opening more than one editor on the same file": "Split views" inside the editor window would probably solve the problem. But I personally would much prefer opening the same file in a separate window. Chily
We are not going to be able to consider this request for 2.0. Consider post 2.0
This would also be a very useful feature for multiple monitor systems. This would allow you to have eclipse maximized on one monitor and have floating editor windows on the other monitor. Even better would be to allow floating windows to dock together. For example, drag one editor out of the main workbench window so that it becomes a floating window. Then drag another editor over the first and they dock together to become a single window with two editor tabs (like they would in the main window). This should work for all dockable views, for example, you could drag the packages view out of the main workbench window and have it float by itself or dock it into the window with the previously mentioned editors.
Reopen to investigate
See also bug 37997 and bug 52685.
*** Bug 52252 has been marked as a duplicate of this bug. ***
*** Bug 64273 has been marked as a duplicate of this bug. ***
Is this request being investigated for any version in the near future (e.g. 3.x)? Also, if bug 8886 and bug 77174 are both resolved, will that result in floating editor windows on OSX? Or, does that involve additional effort?
In Eclipse 3.0 it is possible to detach views to display them on a second monitor. However, this feature does not work for editors. Most developers want to have multiple editors open that they can arrange on a second monitor.
I would be great to use the editor window on the second monitor. (like the help window) Many of my colleagues miss this feature .
I would really like this feature. Here's a use case for you: I'm deploying a new RCP-based application I wrote internally to our Olap testing department at SAS. These folks are not programmers, and they just want to use the application to run tests. They don't know anything Eclipse. I have one Console view that shows test results, and you can click on a result to open an editor on those results (it's just a text file). I showed them how you can tear off the Console view, but what they really want to do is leave the Console view where it is and tear off the editors!. Or they want to just have the editors open in seperate windows in the first place. I'm using the standard Workbench and presentation because I don't want to spend a lot of time writing this tool. In the spirit of RCP I just want to write the unique bits (that select and run tests). This seems like a pretty basic non-esoteric request. I hope nobody minds and I'm not breaking any bugzilla etiquette but I'm going to try and move this back to the platform ui inbox to get somebody to notice the request since it's been languishing for a while.
The bug is much more likely to be tracked while it's assigned to someone who can fix it than when it's in the inbox. This is almost certainly languishing because it's a lot of work to fix - not because nobody noticed.
Ed, we had already assigned it to Eric who owns this component just a few days ago. YOU FAIL AT BUGZILLA. :)
*** Bug 120910 has been marked as a duplicate of this bug. ***
I for one don't want to see the hard problem of allowing multiple editors stand in the way of the less hard problems of things like missing maximize buttons or the ability to move the one-and-only editor to another window.
You sure Kim? According to https://bugs.eclipse.org/bugs/show_activity.cgi?id=8886 it was assigned in July. Anyway, I'll leave the assignments alone from now on. (Though it would be a tempting April 1st trick to go through the db and assign all bugs to Kim :)).
BTW, didn't dragging parts *into* the Workbench used to work? In recent builds you can only drag *out*, and to get them back in you have to use the system menu and turn off the Detached option.
Ed, I just tried detaching and re-attaching a view using hte 3.2 M4 build and it seems to work fine (for me...;-). Check it out and feed me some more info if you're stil having problems...
Doesn't work for me. I don't get a cursor change when I'm dragging a detached window over top of the Workbench window. I'm using Windows XP, SP2, jdk1.5.0_02\bin\java.exe with manifest .
Ed, to re-dock floating views to the workbench window, you have to drag individual view tabs, not the floating window title bar. I think this has been introduced with bug 58003 to overcome accessibility issues such as unwanted docking when moving a floating window. However, this doesn't have much to do with floating *editor* windows ...
OK, but what about the missing mimimize and maximize buttons, which is all this particular kvetch ever complained about?
So far (today!) I've seen traffic on no less than three separate defects (enhancement requests); each regarding detached windows: this one, bug 121748 and bug 120910. I -know- that there are a few dup's also in my 'assigned' bin. Before this gets too out of hand I'll try to scrape together all the related defects and construct a 'core' defect(s) to use to capture the various points and relate all the other defects to it...
Just as a starting point for this particular enhancement could folks please outline some of the -actual- workflow scenarios under which you would prefer to have a 'detached' editor? My guess is that it's going to be easier to support this functionality using new Workbench windows (a la 'Window -> New Window') than it will be to 'enhance' the current detached views to the point where they could support editors; mostly because we'd need the full command support (main menu / toolbars...). If I can get enough use cases I might be able to provide some GUI hooks to create new top-level windows in a fashion that would cover off the requirements outlined above. Try to let me know: - The scenario (i.e. what you are doing when the need to have a detached editor shows up?) - How you think the editor should be opened (drag the tab out like detaching a view, new Open in New Window' menu entry...)
I'll kick this off by paraphrasing Stefan's workflow: The scenario: I have two main windows open; a 'primary' one that is used to edit files and a 'secondary' one that is used to 'view' files. Gui Access: I want a way to specify the 'secondary' window as the location where editors opened by 'search' operations (F3, via the type finder...) are placed while leaving files opened 'directly' (i.e. from the Package Explorer) continue to show up in hte 'primary' window. NOTE: this simply one of many possible workflows...I'll need more input in order to get this to the point where it's even somewhat intuitive...
One usecase I have right now is that I have written an RCP program that can view test output log files. You run a test, a summary goes to the Console view, then you click on a filename in the Console view and it pops open an editor. Right now, it opens an editor tab in the same workbench window (editor area abive the Console view). However some users have indicated they'd prefer it if it opened a detached editor window for each log file they click on. This would allow the RCP app to just have a single standalone view (the console) and separate windows for editors. Note I can't really use views instead of editors because I am reusing the standard text editor and compare editor. Well, not without more work than I want to put into it anyway. Opening new Workbench windows, although I support that, is not quite what they want because that would give them a copy of the Console view in each Workbench window which would confuse them. The users are not programmers or developers so they have a low tolerance for strange UI quirks like that. An option that might satisfy them is MDI support, allowing internal overlapping windows for editors. See bug 29891 comment #29.
Re: Comment 23 That isn't precisely my workflow. It's more like this: - The main monitor (containing a maximized Eclipse window) is used for the primary task, the second monitor is used for reference material. - Usually I will browse code in the main monitor for a while, then when I find a class I'm interested in, I move it to the second monitor. - I always want F3 to open the editor in the same window. You've correctly observed that I frequently move something to the second window after hitting F3, but that doesn't mean I want this to happen automatically. Moving something to the second monitor, for me, means "this is interesting, keep it around". I might pass through a chain of F3s before I reach that point, and I'd find it annoying if the intermediate files ended up on my second monitor -- for much the same reason most people would find it annoying if every website they visited ended up in their bookmarks. Also, when something opens on another monitor, it ends up outside the user's visual range, and the user is left with the impression that nothing happened.
Re: comment 14 > the ability to move the one-and-only editor to another window This is actually harder than simply detaching them. AFAIK, here's the problems involved in moving an editor to another workbench window: 1. You can't change the result of IWorkbenchSite.getWorkbenchPage() -- in other words, once you've told an editor what its page is, you can't change your mind. Suggestion: Give each editor it's own virtual IWorkbenchPage instance that delegates to the real thing. Rather than moving the editor to a new page, just redirect the virtual IWorkbenchPage to the new page. 2. AbstractTextEditor (and many other editors) hook listeners on the Shell. If we move the editor to a new shell, it will detach the listeners from the wrong place and the whole editor will leak. Some editors also cache their shell. Suggestion: No way to write a virtual Shell. Each editor that uses this pattern will need to be refactored. New listeners may need to be added to the editor site to make up for any missing information. Suggest adding an opt-in field to the editors extension point indicating whether the editor is known to support reparenting. 3. It's currently impossible to reparent an IActionBars. Editors use these for their menu contributions. Views don't have this problem because their action bars are all top-level. This one is very tricky no matter how you spin it. I suspect that this may be the blocking issue, although it might be possible to reparent editors that don't use an IEditorActionBarContributor (sadly, this wouldn't help any of the Eclipse text editors). Note: moving an editor to a new top-level workbench window would require fixing all three issues, but moving the editor body to detached-view-style window would only require fixing issue 2 (the menu contibutions would need to stay behind in the main window). Solution: Create a new editor API and write new editors One solution may be to invent a completely new protocol for editors (IReparentableEditor?)... one that doesn't get access too all the site APIs that are non-reparenting-friendly. Anyone who implements the new interface (and not the old one) could be easily reparented, but that would require refactoring any editor that wants to support reparenting... and any editor that permits subclassing (like AbstractTextEditor) would be stuck in the old world forever. Solution: Recreate the editor Rather than attempt to reparent the editor, create a new editor on the same input in the new window. Copy the current cursor position, selection, and scroll position from the original. Drawback: if the editor doesn't support a shared model, this will destroy all user data in a dirty editor. This would need to be an opt-in feature. Eric suggested this to me a while back and I didn't like it, but the more I think about reparenting IActionBars, the more appealing it sounds.
Thanks folks...keep it up. This is all proper grist for the mill...;-).
When I edit in eclipse, I usually end up maximizing the editor. However, if I do anything else, my editor window gets shrunk back down to 1/6th of the screen so that the other pane can be displayed. My workflow consists of a lot of maximizing the editor window, restoring the editor window so I can see another pane, then maximizing again. The obvious "solution" is to resize my editor pane so that I can see both a fairly big editor, and the pane that I'm interested in. This works great until I want to see a new pane that I don't have room for on the screen. At that point, my workflow includes reconfiguring all the pane sizes so that I can see what I need, then switching them all back. The real solution is to undock the editor and other panes from the eclipse shell. Then I can resize my editor the way I want in a separate window - the other "panes/windows" would come up in front of the editor, but just clicking on the editor again would get me back to where I was. I think this is a huge usability issue and should be implemented as soon as possible.
I'm always fiddling with my view/editor panes and something just doesn't feel natural. I wonder if an expose' like feature would be good here. Or maybe MDI for the editors. Just thinking out loud.
> - The scenario (i.e. what you are doing when the need to have a detached editor > shows up?) As some others do, I use a multiple monitor setup (3 or 4 heads), which means that detaching views is far preferable to stretching the main Eclipse window across screen boundaries. At times I want to edit two or more classes in parallel, say because they have a producer/consumer relationship. I can open multiple Eclipse instances, but there are drawbacks to that approach. > - How you think the editor should be opened (drag the tab out like detaching a > view, new Open in New Window' menu entry...) Both options should be available, of course! :-) I'm more likely to drag the tab out, I think, given my experience with Eclipse so far.
I am developing an RCP application for image processing. For this particular application, it is quite common for multiple similar images (or multiple versions of the same image) to be considered at the same time. Being able to align them vertically or horizontally as well as adjust their size is important. For now, I have a popup window that has some limited editing functionality, but I would prefer not to have to maintain two different components.
Some of these scenarios (i.e. Dan's last one) look like they might be solvable by using the current 'split' support. You can drag an editor -within- the editor area and cause it to split the editor area into multiple parts. This is useful for comparison reasons. I've already brougth up the idea that the editor's 'maximize' should actually max the editor -area- rather than the discreet editor so that we can use the maximized version for comparisons (surely a case where you need a lot of editor area...).
My use case for multiple editor windows, coming from emacs, is simply being able to view multiple files at any time, or being able to view one file at multiple places. In emacs, all the windows (frames in emacs-speak) share a common context of open files (buffers), and one buffer may be open in multiple frames at any time. It is also easy to open another frame and change the buffer visible in any frame. From these features comes the following workflow: There are always multiple frames open, with generally only one being used for editing at any time. Whenever something needs to be kept visible for reference, a new frame is opened for it, and stuck to some place on the desktop where it is visible. These reference views certainly don't need a package explorer and whatnot. Sharing the context of open buffers between frames means that it's easy to open any buffer that has been opened in past into any frame that is open, so things that aren't visible don't actually disappear anywhere. My work-emacs currently has about 350 buffers open. The current (3.2) Eclipse supports having editors open in multiple windows, but since the list of buffers isn't shared between windows, I constantly find myself having to locate files in a hard way, even though they are open in an editor tab in another window, which I'm using for reference or writing code, and thus can't be changed to the file right now. Also, it is relatively hard to open a new window and open a given file in it in Eclipse. In emacs there is make-frame-command, which opens a new frame with the buffer that was visible in the previous frame. In Eclipse it seems that I have to first create a new window, then somehow find the file I want to view in that new window. Ie. there is no way to say open-a-new-window-with-editor-that-shows-current-file.
This could be part of the 'component presentaton' story...
For all these use cases, all that needs to happen is to make editors detachable and reattachable just like views, right? If you could right-click an editor's tab and select "detach" (or hit magic key combo), then is bug is basically resolved. Or is there something more that I'm missing?
(In reply to comment #35) > For all these use cases, all that needs to happen is to make editors detachable > and reattachable just like views, right? If you could right-click an editor's > tab and select "detach" (or hit magic key combo), then is bug is basically > resolved. > > Or is there something more that I'm missing? That would be a huge step forward for my use of Eclipse. I'd love to have multiple tab panes in those detached views, which I cannot do today, but I would be thrilled with any improvement over today's implementation.
*** Bug 110012 has been marked as a duplicate of this bug. ***
*** Bug 209312 has been marked as a duplicate of this bug. ***
This feature would be an great addition to further the RCP, especially for apps that aren't as editor-centric as IDEs.
In e4 we'd ideally be able to 'host' what is currently either an editor or a view anywhere in the layout. The choice of limiting its location to an editor area should be enforced through some 'policy'. Note that it's not really that simple, mostly due to the ingrained differences in how the Menu/TB are handled for editors (i.e. any place hosting an editor would -require- a 'main' toolbar to host the editors tools. We should be ensure that both editors and views look the same on the inside but can be made to exhibit different behavior/constraints in the UI (in order to be able to reproduce the existing UI).
*** Bug 294276 has been marked as a duplicate of this bug. ***
Eric, since this is supported in 4.1 I think we can close this?
Tested this in I20110127-2200 (4.1 SDK)...seems to work fine. Combined with 4.1's ability to have sash structures in a DW this is likely OK to close. Note that for some of the other excellent suggestions (i.e. having the ability to define 'primary' and 'secondary' editor stacks) please feel free to open a new defect, referring back to this one if you want. This is an excellent example of the promise of E4...we can fix things that we just *couldn't* fix in 3.x...
