Community
Participate
Working Groups
A thing I used to do in Eclipse 3.x is to open two editors and maximize the editor area in order to see moth of both of them. There is no "editor area" anymore and therefore I can only maximize one or the other editor. Is there a similarly convenient way to do such things in Eclipse 4?
I'm also unable to split the editor area in M5 but I'm certain this used to work in previous milestones.
Works for me with I20120210-1700 on Windows 7.
It didn't work in M4 on my mac. In M5 (maybe it was there in M4 also) I now found the two little minimize/maximize icons in the upper right corner. With that it works on my machine (mac) as well. However double-clicking the tab of an editor doesn't work, but double clicking the thin grey area above the editors will do the trick.
(In reply to comment #3) > It didn't work in M4 on my mac. > In M5 (maybe it was there in M4 also) I now found the two little > minimize/maximize icons in the upper right corner. With that it works on my > machine (mac) as well. Ah, you were looking for that, sorry about that. I assumed people maximized with Ctrl+M. Glad to hear that it's working for you now. > However double-clicking the tab of an editor doesn't work, but double clicking > the thin grey area above the editors will do the trick. This however is a bug.
Not really sure if this constitutes a bug. Were we to allow a double click on one of the editor stacks the intent would be ambiguous; you want it to toggle the shared *area* state but it could also mean that you want to see only the editor in the stack you double-clicked on... For my money I'd make the shared area's 'stack' bigger but there's still too much screaming about wasted real-estate...;-).
(In reply to comment #5) > Not really sure if this constitutes a bug. Were we to allow a double click on > one of the editor stacks the intent would be ambiguous; you want it to toggle > the shared *area* state but it could also mean that you want to see only the > editor in the stack you double-clicked on... IMNSHO it should preserve the behavior from 3.x, which was to maximize the editor area, leaving all editor splits visible.
I think it is quite a common use case to have two editors side by side. At least a menu item or shortcut should be available to expand all visible editor areas to fill the whole screen. Currently there is too much excise when working with multiple editor areas: 1. open editor one 2. open editor two in same editor area 3. Press CTRL-M 4. Drag and drop editor two to free space: editors are shown side by side 5. Change something in editors 6. Press CTRL-M to refocus on package explorer After the last command I would expect that another call to CTRL-M would restore the old setup with the two editor areas. But it maximizes the focused editor. It would be very helpful if it would restore the old setup.
(In reply to comment #7) > After the last command I would expect that another call to CTRL-M would restore > the old setup with the two editor areas. But it maximizes the focused editor. > It would be very helpful if it would restore the old setup. When I split the editor area, CTLR+M will maximize the editor area (both editors now take up the entire workbench window). Eric, this might be a problem where it's hard to tell the difference between splitting the editor area and moving an editor out of the editor area. PW
I suspect that it's a confusion about the shared area... The area containing the editors (whether split or not) is shared between the various perspectives. In this case you maximized the *area* with Ctrl-M, then split it. At this point both editors are still within the (currently maximized) area. This is by intent, allowing the comparison of editor contents whilst maximized. Is the request to then allow an operation that permits showing only one of the two editor stacks while the area is maximized ?
Depending on how you drag an editor when it's maximzed, sometimes it ends up in the shared area and sometimes we create a new stack beside the shared area. The DND rectangles are slightly different, but maybe they're too close. The behaviour expected was to have the editor area maximized again, so both editors were visible. PW
Ah, thanks for pointing that out. Indeed there are two slightly different rectangles. I did not realize that up to now! (Note that the new look and feel for the DND actions with bright green colors on Linux is quite uncommon and may lead to several problems. The old design in Eclipse 3.x is much better: for each DND operation it is always obvious where the dragged part would appear - in Eclipse 4.x this is not. E.g., when dragging a view to create a new tab in the same area is also hardly visible on Linux. I think that part of Eclipse 4.x is a step backward in usability...)
+1. it is too easy to want to take two editor tabs, put them side by side and maximize to have both editors side by side still, but all views minimized... and end up just maximizing one of the editors The annoying thing is even when you finally train yourself to spot the subtle distinction of editor splitting... that once you have the editor area with two editors side by side... if you double click a tab it doesn't react in a way that you might expect (yes, just maximize everybody rather than sitting there doing nothing)...
Will this ever be fixed?
No one is looking at this ATM, but we accept contributions. PW
The platform has no intent to work on this but would be more than willing to look at Gerrit patches...that's what we use the 'helpwanted' tag to indicate. Note that this would entail somehow making the MArea's composite use a TrimmedPartLayout (to allow for putting the editor what was 'minimized' into the *area's* trim). This might also mean generalizing the layout so that it has no idea it's under a Shell. Then you'd have to change the MinMaxAddon to understand the new configuration...
New Gerrit change created: https://git.eclipse.org/r/145671
*** Bug 395356 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/145671 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=41448180d967546a653e40b1ff9546d111b5ecf6
Thanks Robert and Benedikt for fixing this
(In reply to Eclipse Genie from comment #18) > Gerrit change https://git.eclipse.org/r/145671 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=41448180d967546a653e40b1ff9546d111b5ecf6 > We're at the beginning of the new release, hence make sure to increment the bundle version if you merge the first change after 4.14. I've fixed this now.
(In reply to Dani Megert from comment #20) > (In reply to Eclipse Genie from comment #18) > > Gerrit change https://git.eclipse.org/r/145671 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=41448180d967546a653e40b1ff9546d111b5ecf6 > > > We're at the beginning of the new release, hence make sure to increment the > bundle version if you merge the first change after 4.14. I've fixed this now. Sorry, of course a overlook at my side. Also a side effect of not having to rebase if there is no overlap in Gerrit. Good practice would be to rebase Gerrits before pushing on a new release. Might be good to document that somewhere (and if possible enforce)
(In reply to Rolf Theunissen from comment #21) > (In reply to Dani Megert from comment #20) > > (In reply to Eclipse Genie from comment #18) > > > Gerrit change https://git.eclipse.org/r/145671 was merged to [master]. > > > Commit: > > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=41448180d967546a653e40b1ff9546d111b5ecf6 > > > > > We're at the beginning of the new release, hence make sure to increment the > > bundle version if you merge the first change after 4.14. I've fixed this now. > > Sorry, of course a overlook at my side. Also a side effect of not having to > rebase if there is no overlap in Gerrit. Good practice would be to rebase > Gerrits before pushing on a new release. Might be good to document that > somewhere (and if possible enforce) No worries! That's the consequence of the new rebase strategy, which is better in most cases.
*** Bug 423863 has been marked as a duplicate of this bug. ***
