Community
Participate
Working Groups
I started using TPTP on 3.1.1 and noticed that the Profiling perspective does not have an "Editor content area" i.e. the panel where each newly opened file comes and sits in a tab - refered to as "Editor Panel" henceforth here. This was new to me in Eclipse because minimizing the "Editor Panel" makes it sit awkwardly in a corner disrupting the flow of the screen. I also noticed that if you open a new file in the Profiling perspective or do a Window/New Editor the "Editor Panel" gets created. And, if you reset the Profiling perspective it removes the "Editor Panel". This is wonderful. So, if we have this capability why not just remove the "Editor Panel" when all files are closed ? We only use the Java and Java Browsing to open files. But once a file is opened in some other perspective the only way to get rid of the "Editor Panel" is to reset it and lose your customisation. What do you guys think ? PS: I also noticed in 3.2M3 resetting the Profiling Perspective does not remove the "Editor Panel" is this a feature we lost in 3.2 ? - Bug ?
Paul: I think this is more your kind of stuff. If I've judged wrong, please feel free to bounce it back to me.
I agree with this. The editor area should not be so special, it should work like views. When you close all the views in a stack, the other workbench parts resize to fill the unused space. Editors should work the same way - when you close the last editor in a stack the other parts should resize to fill the space instead of leaving a big gray rectangle. See also bug 94191 and bug 100428.
I disagree. At least in the IDE case, closing all editors is a common occurrence, and removing the space completely would lead to too much UI instability.
Maybe, it's hard to say without trying it. But I have an RCP app where it would definitely be more usable for that reserved editor area to go away. See also bug 8886.
Why not have a preference/setting that says whether the editor area should auto-hide or not? It could even be a part of the perspective. So instead of having setEditorAreaVisuble(true), you'd have setEditorAreaVisibleAllTheTime(true) instead. When a file is opened, the editor would show/hide if VisibleAllTheTime is false (for RCP apps) and always be preesent if VisibleAllTheTime is true (for IDEs).
I think it is very much relevant and sensible to remove the content area from the perspective. I do not understand the "UI instability" comment (is this from a coding point of view ?). For example; we use the TPTP perspective for profiling only and like to use the full IDE content area for TPTP views. Anyone who has used TPTP will appreciate this (with all the graphs and stats etc). When we want to edit java code we switch to the Java perspective. If "jump to code" or similary action is selected from TPTP ( or any other perspective for that matter ) they should "switch" to the Java Perspective and display the Java file in the editor content area of that i.e. switched perspective. Switching back to TPTP or the previous perspective should not display the editor content area. This is the KEY usability problem I am trying to address by raising this issue. We would like to keep each perspective "objective".
*** Bug 144731 has been marked as a duplicate of this bug. ***
There are currently no plans to work on this feature. PW
I vaguely remember that we had a menu item to explicitely hide the editor area at one point. Is that true? If so, does anyone have the background on why we removed it? (I suspect it was because users found it confusing.) "The editor area should not be so special" is exactly the kind of question we are considering as part of the "Improve workbench usability." plan item (bug 154120). It seems odd that we aren't at least re-visiting whether we want this behavior or not.
There was a menu item that was removed to free up space and because users might find it confusing. It is still available as a command that you can bind to, and run programmatically. IServiceLocator sl = ... partSite or window or workbench; IHandlerService handlerService = (IHandlerService) sl.getService(IHandlerService.class); handlerService.executeCommand("org.eclipse.ui.window.hideShowEditors", null); PW
Eric, what if we added an auto-hide option in the presentation where we check for empty containers? PW
Hmmm, I thought I'd just commented on this but it seems to have been lost so I'll try again. First, user settable options should become a -last resort-; we've taken the easy path far too often and ended up with waaaaay too many options. RCP configurable options are different; the complexity is only seen by product developers (who ge paid to manage the complexity...;-). If we -must 'optionize' this then the correct place to have it would be in the perspective -definition-, not as a user preference. As part of the new minimize work there will be an 'editor stack' that will appear when the editor area is minimized (it'll no longer be as 'special'). This state is perspective based so it can be minimized in the TPTP perspective and not in the java perspective. I'm with Nick that this would drive me nuts...I use "Close all Editors" all the time and certainly wouldn't want the area to go away (since the next thing I do, generally, is to open a new editor...;-).
But if you were working in a perspective that contained many views that could use the space, and opened editors there only occasionally, you *would* want the area to close again. To me this argues that it should be a perspective-specific setting. Whatever gets done though, in 3.3 the hide editor area command better be equivalent to "minimize the editor stack" as Eric described, or we're idiots.
For a related issue: Bug 18460 [WorkbenchParts] 'Hide editors' should deactivate active editor parts PW
Is this planned for 3.3 ?
I hadn't planned on it. As various comments infer, this behavior istn't suitable for the workbench in general and a quick look at IWorkbenchPage implies that clients should be able to implement this behavior should they so desire. You can add a property change listener on "CHANGE_EDITOR_CLOSE", use 'getEditorReferences()' to determine if there are any more open and 'setERditorAreaVisible(false)' to hide it (the inverse code to handle opening the first editor is left as an excercise to the reader). Any state management issues resulting from this code would constitute workbench defect (i.e. they'd be 'my problem'...;-). I'm marking as WONTFIX until somebody can shoot holes in the above approach...
