Community
Participate
Working Groups
Build Identifier: Version: 4.2.0 Build id: I20120608-1400 In Eclipse 3.7.* was possible to move editor window to other window. For example I have one window open on monitor 1 and window open on monitor 2. I try to drag editor window but it not move editor window from monitor 1 to editor window monitor 2 but it opens detached editor window not paste window to monitor 2. It is very tiring since if in Eclipse 4.2 if you want to open opened window I need to find file in second editor and open again it just multiply number of elements. It looks that "green" place from 4.2 works with bugs or not support such usefull feature. Reproducible: Always Steps to Reproduce: 1. Open eclipse. 2. Window -> New Window, move window to other monitor (or to the side if you have one). 3. Open file. 4. Window -> New Editor (it duplicates file). 5. Drag duplicated window to other screen and try to dock new editor into new window - it is impossible - it creates separated window frame. a. only workaround is to open file again in new window. It is very slow since drag and drop not works like in chrome or other application or Eclipse 3.7.2.
I'll put this onto the 4.2.2 plate since I suspect that the fix is trivial; allow drops of *editors* into any window sharing the same MApplication. Note that we can't do this for Views since it would allow us to end up with multiple instances of what should be single instance views (like Outline...).
*** Bug 384810 has been marked as a duplicate of this bug. ***
It is very usefull feature so nice to see faster as you suggest. I have some idea for new feature but not sure how to add this - do you accept feature requst by bugzilla. I mean about another trivial speed up feature like close tabs to left and to the right so I could close past or future - it is very usefull if you edit large programs with multi tabs. Google was add this to chrome (only the right). Astah added this to left or right. It is much better that close other why - I want to save two windows from other so I need left on first and right on other + move if need that is very fast better than manager. Please give hint how to send fetaure request to describe it.
Cezary, we make if *really easy* to submit enhancement requests...open a new defect and change the 'Importance' from 'normal' to 'enhancement'. Note that managing the tabs (especially for editor stacks) has been an on-going struggle with many different variations over the years so something like your suggestion of 'close to the left/right' isn't likely to be possible because there are modes where the editors are not actually maintained in the order in which they open. But keep thinking of ways that we can improve your experience !!
(In reply to comment #4) > Cezary, we make if *really easy* to submit enhancement requests...open a new > defect and change the 'Importance' from 'normal' to 'enhancement'. > > Note that managing the tabs (especially for editor stacks) has been an on-going > struggle with many different variations over the years so something like your > suggestion of 'close to the left/right' isn't likely to be possible because > there are modes where the editors are not actually maintained in the order in > which they open. > > But keep thinking of ways that we can improve your experience !! Thanks for info. Eric I am sure that it is not matter "order of open" but "order to close" - I am assume that if main window could render tabs in order it is possible to send from controller to view command to close tabs in orders like I do with mouse. Not sure if there is such text editors which cannot be closed by mouse? I think you are more experience but I am sure that "close left", "close right" is more important than "close others" and efficient. Common problem is that I am opening windows is faster than closing I am mean programs about 100k lines with active modifications it will be not need for begginers.
*** Bug 384967 has been marked as a duplicate of this bug. ***
I was shocked to encounter this regression. Definitely an essential feature for development with multiple monitors.
Another wrinkle to this is that dialogs used to support multiple windows. For example, say you launched the find dialog (ctrl+f) while focuses on an editor in Window 1. In prior versions you could select an editor in Window 2 and continue to use your existing find dialog in the new editor.
*** Bug 390824 has been marked as a duplicate of this bug. ***
*** Bug 392117 has been marked as a duplicate of this bug. ***
in DnDInfo.getModelElement(Control ctrl), there is the following code: if (modelService.getTopLevelWindowFor(element) == topLevelWindow) return element; return null; It checkes whether the drop window is the same as current window. Disabling the condition makes the drop work on other windows as well. I will have to test that (and also make sure that views are still prohibited from being dropped to another window) and then I will submit a patch.
Created attachment 225577 [details] patch v.1 Here's my proposition of the patch. A few remarks: - my method of telling a view from an editor doesn't seem to be bulletproof. Better ideas are more than welcome - anyway, the "allow DnD'ing editors across windows, but not views" approach seems to be a heuristic. The correct algorithm should be: 1. if drag element is an editor - allow 2. if drag element is a view that can be duplicated (like Call Hierarchy) - allow 3. if drag element is a view that cannot be duplicated (like Outline), but an instance of this view does not yet exist in the target window - allow 4. otherwise - disallow. (the patch only implements the heuristic approach, though).
Piotr, the logic for determining whether the drop window is a candidate could simply extend the current test to ensure that both top-level window's parents are == (i.e. they share the same MApplication)... Thanks again for the patch. I'll be getting to these once 4.2.2 ships...
In theory you could workaround by dragging the editors/views you want into new windows (rather than creating a New Window using the menu). But then they all get activated together as I describe in bug 398325.
Should fix this for Luna (and perhaps 4.3.1 since it's a regression).
Eric, have you checked my patch already? do you think it's a good candidate for a commit?
A derivative of this behaviour now works in Luna. In Indigo and earlier (see the description in https://bugs.eclipse.org/bugs/show_bug.cgi?id=384810) the entire code editor window was a drop target for the dragged source code tab, in Luna you have to very carefully drop the dragged tab onto the appropriate tab bar as it seems to have inherited a browser-tab-alike user experience where you have to drop the tab onto the tab bar rather than the code window itself. There is also no visual feedback that an action is being performed, either in the original window or the destination window. After testing: Indigo: Shows a "folders" icon (3 stacked folders) when dragging and there is a valid drop target (the entire code window or an open source code file) Luna: The "arrow" cursor, at all times. A light grey vertical line on the tab bar of a window when hovering over it.
Luna implementation is quite poor. When an editor is dragged from one window to another certain features cease to function. For example, open a new windows, then drag an editor from the old window to the new window. With focus in the recently moved editor, hit ctrl+l (or whatever you have go-to-line bound to) and witness it do nothing. Now move the editor back to the original window and try again. It will now work. In addition to broken functionality with editors that have been moved, there are other issues if you have an editor in multile windows for the same file. I'm not sure what causes this, but you can get eclipse into a mode where as soon as you edit text in one editor the editor in the other window will scroll-to-line, which basically defeats the entire purpose of having dual editors in the first place. Back to 3.8 :(
The 'del' key also stops working. Most annoying, and makes using multiple source windows (in my case, up to 5 at a time across multiple monitors and workspaces) annoying.
This bug is a bit of an annoyance for me. Some of you are probably already aware that floating windows always have the same focus as their parent window. This is problematic for multi-monitor users. For example, lets say I drag a floating window to my second monitor. I then go back to working in the main window. On my second monitor, I get a notification from my email client or a meeting reminder. However, because the focus of the floating window is bound to the parent window, when I shifted focus to the main window, the floating window covered up the notification. I have missed more than one meeting because of this. The solution USED to be that you click Window->New Window and place what would have gone in the floating window in that new "instance". Focus is not bound, so it won't block anything important items that come up on the secondary monitor. I'm working on a large project right now, so I actually like to dock package explorer on my secondary monitor (in portrait for maximum visibility). I don't need it on top all the time when I'm workin on the primary monitor. So I try to create a new window, only to find that I can move source code editors opened in the package explorer instance back to my main instance. In short, either fix this bug or the bug that ties the focus of floating windows to their parent windows (or at least let us minimize floating windows).
This one is a duplicate of 346009, not sure though that the 21 votes are transferred to that bug. The first attempt to fix Bug 346009 showed that its a bit tricky to get all the behavior correct. *** This bug has been marked as a duplicate of bug 346009 ***
