Community
Participate
Working Groups
Build Identifier: 20100917-0705 1. Please make it possible to tear a tab from window and drop it in antoher Eclipse window (which was created with Window -> New Window) - much like you can tear a Chrome tab from one window and drop it in another. Currently, the tab will not drop in another window and stay orphaned on its own frame in the other monitor and will not sttach to any tab group in the second window (will only attach to window it was torn from). 2. When i have two windows open in the same process (Window -> New Window), one with Java Perspective showing the project explorer tree menu and Java Editor Window - and the second with Java or Debug perspective, with Problems/Console/Search/Progress/etc open. Right Click -> References -> Project If i have the search result tab moved to the other window, i'd expect the results to appear in that one. However, Eclipse opens up a new search tab in current window in spite of me moving the tab to antoher window where it remains blank. Console output seems to go to other window fine, but not searches and the results of some other actions. Please make this more consistent - if i have moved the tabs to antoher window, i'd like the output to go there too. Thanks Reproducible: Always Steps to Reproduce: 1. Attempt to drag a tab from one Eclipse window to another Eclipse window in the same process. 2. 1. Window -> New Window 2. Close Problems/Console/Search/Progress/etc in first window, open in second window 3. Right click in first window -> References -> Project 4. A new search window is opened in current window instead of directing search output to existing search result tab in other window where i ahve moved it.
There's probably an existing enhancement request about this.
David, a 'New Window' is a separate grouping of views/editors/perspectives, independent of any other top-level windows. It's not as simple as implementing the drag and drop operation since there are concepts like 'singleton' views which would have to be taken into account. More importantly there is no cross-communication between the windows so even were you to drag the Search view to a different top-level window we'd have no way to 'know' that it was supposed to respond to searches in a different top level window (indeed that would be considered a defect by many folks). Perhaps a Detached Window (DW) would be a better option for what you want. This allows for a stack to be 'detached' from its presentation (so you can dock it on your secondary monitor) but it's still part of the same top-level window's layout, meaning that a search in the 'main' window will correctly show its results in the DW. In place of: 2. Close Problems/Console/Search/Progress/etc in first window, open in second window Try right-clicking on the stack (just to the right of the tabs) and select 'Detach' from the context menu. Then drag that window to where it's most appropriate. Let me know if this helps...
Hi Eric, answers below.. >not as simple as implementing the drag and drop operation since there are concepts like 'singleton' views are you saying its possible or not possible, or that there is some artificial restriction in that it doesn't adhere to some pattern? I'd like if there was some way that i could move (or copy) an editor tab, for example, from Debug perspective window into Java perspective window. >More importantly there is no cross-communication between the windows If so, why does console output and the result of some toher actions go to the toher (secondary) window when you run it from the main window. There seems to be quite a bit of inconsistency. >we'd have no way to 'know' that it was supposed to respond to searches in a different top level window can you add something which makes this possible? >Perhaps a Detached Window (DW) would be a better option for what you want No, this is not what i want. This is essentially an orphaned tab/tab group that floats on its own***. I would rather have multiple non-duplicate tab groups in a separate window in my other monitor (e.g. Java perspective in one, Debug in the other), which would not clutter up my desktop like multiple detached/orphaned windows would. The other bad alternative is stretching my one main Eclipse window across two monitors. I'd like it if you could improve inter-window communication so i can reduce clutter and get full benefit out of having two monitors. (***As well as this, even were i to do this - I have to go through and Detach each tab and then re-assemble them in a separate tab group) rgds, David (In reply to comment #2) > David, a 'New Window' is a separate grouping of views/editors/perspectives, > independent of any other top-level windows. It's not as simple as implementing > the drag and drop operation since there are concepts like 'singleton' views > which would have to be taken into account. > > More importantly there is no cross-communication between the windows so even > were you to drag the Search view to a different top-level window we'd have no > way to 'know' that it was supposed to respond to searches in a different top > level window (indeed that would be considered a defect by many folks). > > Perhaps a Detached Window (DW) would be a better option for what you want. This > allows for a stack to be 'detached' from its presentation (so you can dock it > on your secondary monitor) but it's still part of the same top-level window's > layout, meaning that a search in the 'main' window will correctly show its > results in the DW. > > In place of: > > 2. Close Problems/Console/Search/Progress/etc in first window, open in second > window > > Try right-clicking on the stack (just to the right of the tabs) and select > 'Detach' from the context menu. Then drag that window to where it's most > appropriate. > > Let me know if this helps...
I too would like this functionality. VB6's IDE has it, and it works great for multiple monitors.
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. If you have further information on the current state of the bug, please add it. 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
