Community
Participate
Working Groups
SDK 4.0 build, I20100413-1143, Win7. I really miss being able to double click on a tab and get the maximized editor. (And the min/max controls). Eric, if you think it's something a "layman" can do, point me where to look and I'll see about fixing it.
I'm missing most of the general editor management features in my day to day use. For example, "close others" on the tab menu, etc.
With Eclipse SDK 4.0 in mind this is almost a blocker.
Susan, take a look at the 'MinMaxAddon'. Feel free to remove the current hacks that mess with the CTF's buttons, they are there only to allow clicking on the 'restore' button of a visible minimized stack. A 'maximize' can be paraphrased to be 'minimize all stacks except the one being maximized'. You'll have to 'tag' any stacks minimized as a result of a maximize operation so that on a restore you can restore only those stacks that are in the trim as a result of the maximize (as opposed to stacks that might have already been explicitly minimized. The main 'gotcha' issue (as it was in 3.x) is what to do with a minimized Editor *area*. One shortcut may well be to only allow 'maximize' to take place *on* the editor area. OK, we lose the ability to maximize a view but IMO that's less important than maximizing the EA... Also, I've been considering making the MinMaxAddon a service in order to encapsulate the hacks creeping into the code (i.e. knowing the magic format for a TrimStack's elementId and parsing out the perspective id...). What do you think?
Created attachment 173919 [details] Implements the maximized behavior for the Editor area Works quite well except for some edge conditions: The EA stack's button state isn't correctly reset on a restart No key binding yet (I'm trying to hack the MaximizePartHandler but it looks like I'll have to move the code into the model service first).
Committed in >20100709. Applied the patch... I won't mark this as fixed yet until some of the other edge conditions are solved.
Created attachment 173963 [details] Implement perspective and restart handling NOTE: this patch also includes an implementation of WorkbnchPage#toggleZoom that works only against the editor area. Still need to work on DnD polish like tagging a split Editor Stack as one...
Committed in >20100711. Applied the patch.
(In reply to comment #1) > I'm missing most of the general editor management features in my day to day > use. For example, "close others" on the tab menu, etc. Eric, should I open a separate bug for "close others" and "close all"?
Eric, this does not work in SDK 4.0 - I20100712-2029.
(In reply to comment #9) > Eric, this does not work in SDK 4.0 - I20100712-2029. Dani, does it work for you in a new workspace?
(In reply to comment #10) > (In reply to comment #9) > > Eric, this does not work in SDK 4.0 - I20100712-2029. > > Dani, does it work for you in a new workspace? A new workspace does not have any files and hence no editor to maximize ;-)
(In reply to comment #11) > > Dani, does it work for you in a new workspace? > A new workspace does not have any files and hence no editor to maximize ;-) Actually, the editor area still has the icon so you can still maximize it. :P Ctrl+M also works for me.
(In reply to comment #12) > (In reply to comment #11) > > > Dani, does it work for you in a new workspace? > > A new workspace does not have any files and hence no editor to maximize ;-) > > Actually, the editor area still has the icon so you can still maximize it. :P > Ctrl+M also works for me. Please read comment 0.
I double-click on a specific (and non active) editor tab to maximize it.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > > Dani, does it work for you in a new workspace? > > > A new workspace does not have any files and hence no editor to maximize ;-) > > > > Actually, the editor area still has the icon so you can still maximize it. :P > > Ctrl+M also works for me. > > Please read comment 0. Touche. Don't I look dumb.
Created attachment 174147 [details] Allow Double-click to maximize
Committed in >20100713. Applied the patch.
The only glitch is that you can double click anywhere in an empty editor stack to toggle the maximized state (is this a feature or a bug?).
>The only glitch is that you can double click anywhere in an empty editor stack >to toggle the maximized state (is this a feature or a bug?). A nice feature (same in 3.x ;-)
Marking as FIXED. We should open new defect to cover cases that arise now that minimized views are becoming popular (i.e. I seem to remember adding special code to manage the interaction between the view itself and the editors opened through it...).
(In reply to comment #1) > I'm missing most of the general editor management features in my day to day > use. For example, "close others" on the tab menu, etc. Opened bug 319800 to track this part.
I'm sorry, this does not yet work correctly: if I double-click on a non-active tab it only activates the editor instead of maximizing it as expected.
(it works for the active editor using I20100713-2016).
(In reply to comment #22) > I'm sorry, this does not yet work correctly: if I double-click on a non-active > tab it only activates the editor instead of maximizing it as expected. Odd, this seems to be working correctly for me.
>Odd, this seems to be working correctly for me. Did you try it on a non-active tab using I20100713-2016?
(In reply to comment #25) > >Odd, this seems to be working correctly for me. > Did you try it on a non-active tab using I20100713-2016? I'm 99% sure that's what I'm doing. Used a new workspace, made a project, add two classes, opened them both, alternate double-clicking the tab in the back, the editor area maximizes and un-maximizes accordingly.
I am on XP with default blue theme, not the classic theme you use, Dani. Not that I think that matters...
I see the diff: I used a text and a Java editor. Doing this I can also make it sort of freeze.
(In reply to comment #28) > I see the diff: I used a text and a Java editor. Doing this I can also make it > sort of freeze. I tried the same and got it to freeze on one occasion and some flickering/focus problem another time.
Looks like we have a reproducible case. Eric, can you take a look at this?
Dani, when you hit the splitting issue (i.e. no max on a double-click of a non-active editor) could you check to see whether the editor switch is causing the trim to wrap the perspective switcher onto a second line. This is caused by there being more TB's visible for Java files than text files... My suspicion is that in this case the actual editor tab moves out from under the mouse as the new trim wrapping moves the client area down. I this is the case I'm not sure whether we'll be able to address it in the short term; there has always been an issue that a 'double click' both issues a mouse button down *and* an 'Activate' event, either of which will cause the editor you're over to become active (which may cause new TB's and thusly a wrapping of the top trim).
Dani, I just checked this scenario using 3.6 and it exhibits the same problem, if you have the env in a state where selecting the non-active editor you want to double click on would result in the main TB wrapping then the maximize doesn't occur... As far as the 'hanging' issue goes I haven't really been able to repro it. Is it possible that if you do it enough that the 'gc' kicks in and stalls us ? We're likely spamming object creation due to all the context changes...
This seems to work fine now in SDK 4.0 - I20100718-2237.
(In reply to comment #33) > This seems to work fine now in SDK 4.0 - I20100718-2237.
