Community
Participate
Working Groups
20020305 Several of us like to work in a single window (the old "MDI" mentality <g>). We switch perspectives by selecting from the vertical toolbar on the left. We also create multiple Java perspectives by selecting "Perspective->Save As..." and creating a new Java perspective called, say, "Java2". "Editor sharing" is nice most of the time, but in the "Java2" perspective, you do *not* want to share editors. You want a completely separate "Java" context. I realize that the work around for this problem is to open the second Java perspective in a new window. I am hoping that it would not be too difficult to maybe add a "share editors" checkbox (default 'yes') to the Perspective- >Customize... dialog, and then to allow single-window perspective changing to the customized perspectives without sharing editors.
Even better would be to have workbench pages show up as vertical tabs to the left of the shortcut bar. I've read in the build notes (or platform-ui mailing list) that the latest changes to perpectives essentially kill the workbench page concept as each window would have only one page and one set of editors. I think this is a mistake, I suspect there are as many people who don't prefer using seperate windows as there are people who do (me being one who doesn't). Letting windows and pages be converted to each other (by right clicking on a vertical page tab and choosing "Show in seperate window" perhaps) would be a good way of providing middle ground.
PuhLEEZE - do like they say! I don't remember much about Eclipse 1, but I did use WSAD 4 and having different editors in different perspectives made infinitely more sense: Java source in the Java perspective, JSPs and XML in the Web perspective. I always use only one window - does that make me a second- class citizen?
*** Bug 21258 has been marked as a duplicate of this bug. ***
See bug 21258 comment 6 for a scenario.
Reassigning bugs in component areas that are changing ownership.
Created attachment 47333 [details] purpose of document is to propose a solution to this bug(in plain text and ms word)
IMHO a separate "ScopedEditorPart" or "ScopedPerspective" are not the best solution. May I propose to use the normal EditorPart and normal Perspective and simply add an extension point "EditorPerspectiveBinding"?! The EditorPerspectiveBinding would contain to references and one flag: - targetEditorID - targetPerspectiveID - inverse (boolean flag) inverse = false: An editor is shown in all perspectives as long as there is no such binding defined. As soon as at least one EditorPerspectiveBinding exists, the editor is only shown in those perspectives that have such a binding defined. inverse = true: Now the binding would EXCLUDE a certain editor from a certain perspective, while the editor is still visible in all other perspectives. Why this solution: IMHO this solution would allow very flexible definition of the different parts (editors, perspectives and bindings) in different plugins. It's a bit similar to the already-existing PerspectiveExtensions where you can add actions dependent on the perspective. Why not separate EditorPart+ScopedEditorPart / Perspective+ScopedPerspective: Imagine, you want to extend the JDT: There you have the Java source code editors in basically all perspectives and it's good this way. Now I want to add a perspective that deals with sth. different (not java source code, but maybe management of my server farm). That means, I could easily exclude (inverse = true) the java editors from my new server-farm-management-perspective. This would not be possible if a new ScopedEditorPart would be required in the JDT. Marco :-)
just wanted to add: maybe we need a bit more detailed extension point, because it's not yet clear how it affects the behaviour of a perspective: Will a perspective show any other editor, if there's a binding with inverse=false defined? I think, the EditorPerspectiveBinding should therefore have the following fields: - targetEditorID - targetPerspectiveID - visibilityMode Where visibilityMode can have one of the following values: - exclude: The perspective will not show the specified editor, but show all others (unless another binding defines a different behaviour). And the specified editor will still be visible in all other perspectives. - perspectiveHideUnboundEditors: The perspective will not show any editor that has not been explicitely bound by an extension. The said editor will however be visible in all other perspectives (unless other bindings forbid it). - editorHiddenInUnboundPerspectives: The said editor is only visible in perspectives for which a binding exists. The specified perspective will still show all other editors, however. - hideAllUnbound: This is a combination of perspectiveHideUnboundEditors and editorHiddenInUnboundPerspectives, which means: The specified editor is only visible in perspectives to which it is explicitely bound. The specified perspective shows solely editors that are explicitely bound. Marco :-)
Marco, Yes, you're points are correct and, very closely reflects my thinking when I first implemented my solution (I have made changes to platform.internal.ui/plugin.xml, and asked to contribute these), however, when I pitched this to paul webster he said that any proposed solution to this issue must address the corner use cases, with respect to 'inside a perspective' and 'perspective transition' behaviors. I realized that my solution did not consider a few of these usecases, so more thought needs to be given to the solution. Thus, if you read my attachment in my recent post, look at the 'Guiding Principles' section. I think that perhaps, this encapsulates the concerns. Moreover, any propsed solution should not violate any of these principles. ****I should have mentioned this in my post,..sorry about that**** Dennis (In reply to comment #8) > just wanted to add: maybe we need a bit more detailed extension point, because > it's not yet clear how it affects the behaviour of a perspective: Will a > perspective show any other editor, if there's a binding with inverse=false > defined? > > I think, the EditorPerspectiveBinding should therefore have the following > fields: > > - targetEditorID > - targetPerspectiveID > - visibilityMode > > Where visibilityMode can have one of the following values: > > - exclude: The perspective will not show the specified editor, but show all > others (unless another binding defines a different behaviour). And the > specified editor will still be visible in all other perspectives. > - perspectiveHideUnboundEditors: The perspective will not show any editor that > has not been explicitely bound by an extension. The said editor will however be > visible in all other perspectives (unless other bindings forbid it). > - editorHiddenInUnboundPerspectives: The said editor is only visible in > perspectives for which a binding exists. The specified perspective will still > show all other editors, however. > - hideAllUnbound: This is a combination of perspectiveHideUnboundEditors and > editorHiddenInUnboundPerspectives, which means: The specified editor is only > visible in perspectives to which it is explicitely bound. The specified > perspective shows solely editors that are explicitely bound. > > Marco :-) >
Hello Dennis, thanks a lot for your reply! I've actually looked at your attachment, but because of my chronicle time lack, I only wanted to shortly point out issues I see with that solution (separate classes Perspective+EditorPart vs. ScopedPerspective+ScopedEditorPart). Of course, my proposal (or better say ours, if you had similar thoughts already before) was not complete yet. Hence, I'd like to elaborate now a little bit more while taking the "Guiding principles" into account: > 1)No unpredictable behavior. – (substitute unpredictable with non-responsive) I don't see any unpredictable behaviour, if the perspective named "server farm management" doesn't show a java source code editor. IMHO that's absolutely predictable and logical. > 2)Should not violate UI Guidelines Perfect. I don't think that EditorPerspectiveBindings violate UI guidelines. If I'm wrong, please point me onto them. > 3)“If user double clicks a file, they expect to see it.” – Paul Webster I totally agree and I think that's no problem: First, you very likely won't have the Package Explorer or the Navigator in the "server farm management perspective". Of course, you might still open it there, however, or you might open a java source file via the main menu, but in this case, it should open the source code editor in the appropriate perspective (i.e. Java Perspective)! We've already written an extension point for our application, that switches automatically to the 2D-editor-perspective when opening a 2D-vector graphics (IMHO more logical than showing the 2D-editor in the sales-perspective). The only ugly thing is that our 2D-editor-perspective now cannot yet hide non-appropriate editors ;-) > 4)Minimize disruption of current environment behavior/flow. > 5)Should not break current behavior. As long as you don't define EditorPerspectiveBindings, all the behaviour is unchanged. And if you define them, your goal actually IS to change the behaviour ;-) Of course, to separate [Scoped]EditorPart and [Scoped]Perspective into each two classes would solve our problem, because our whole application would then solely use the Scoped versions, but IMHO that would not be useful to the whole Eclipse system. For example, it would add the unnecessary need to maintain two separate implementations that could easily be only a single one. And - as I pointed out before - it would restrict what you can do within the IDE (that probably still uses the non-scoped versions). Marco :-)
Marco, Our proposed solution violates a principle when a user does 'Show View' and opens the Navigator, then clicks on a file. Other than that, I do agree with you. One thing that your solution needs is for targetEditor to be *. That way you can, for a given perspective, include or exclude a set of editors for a given perspective. Then your solution will be *exactly* the same as my initial prop. Another thing that I am realizing about the most recent soln. prop. is that, the scoped editor and/or scoped perspective should not imply that there will be a class and instance of a ScopedEditorPart or ScopedEditorPerspective. From an app. developer's viewpoint, it would be completely declarative in their plugin.xml. Everything, is completely transparent, as far as they are concerned. My current implementation, does not introduce any new classes to the interal package, or anywhere for that matter. Only *very few* changes and additions to the current logic needed to be done.
Created attachment 47493 [details] Modifcations made to org.eclipse.ui.workbench.internal package. Unzip, read the text file, then import the projects in to your workspace. Steps outlined in the text file. Leave feedback/bugs/comments/questions/issues. Dennis
Created attachment 47494 [details] Extra's for the patch: a visualization plugin of the percieved modication implications, and a install/run instructions for the patch itself. Patch install/ run instructions. and Debugging tool/Visualizer...use this navigation tool and explore the possible implications of adopting this behavior into your app. Dennis Park
Created attachment 47495 [details] Class diagram from workbench's modification Some extra material.
Created attachment 47496 [details] Class diagram from workbench's modification
One implication of the current pre-beta patch, worth noting is that an EditorStack can be in 1 of 3 states at any particular time in the runtime environment: 1) Normal 2) Ophaned 3) Adopted I will elaborate on this, with state transition diagram and explanation, very soon. In the mean time, use the Perspective-Editor binding Navigator to see what happens when a user drags an editor out of the editor stack and drops it into the editorArea. (becomes orphaned), then switch perspectives, and reassign to a different editorStack (not originating from the perpsective that it was opened (adopted). Dennis Dennis
Not EditorStack, I mean EditorPane,..sorry for the confusion. To clarify, the stated observation applies to EditorPane, not EditorStack, though it is worth noting that a 'Globally scoped' EditorStack is created when an EditorPane transitions to orphaned state, then disappears when transitioning out of orphaned state into either adopted or normal state.
Have you considered using activities and a perspective listener? By enabling and disabling an activity when you switch perspectives you can add and remove editors from the available list.
Todd, as a general solution? or a workaround to the orphaned behavior?
I think Tod is talking about activities as a general solution. The activity currently scopes visibility of "things" in the workbench window. Things like menu items, toolbar buttons, etc. The use would probably be something like: 1) I create paul.editor.ed1 2) I create an activity paul.activity1 that includes paul.editor.ed1 3) on perspective changes, I enable or disable paul.activity1 Activities/Capabilities is a mechanism already included in eclipse, whose purpose was to control visibility of UI elements without saying anything about their enablement/disablement/abilities. Activities themselves need some more work to be fully up to the task, though. (I'll have to review the bug on Tuesday, we're testing now for 3.3M1 releasing this weekend) PW
I'll try that,..it might be what we were looking for.
Tod/Paul, After further investigations, preliminary assesments suggests that Activities might be a viable solution. However, from a OO design point of view, I find it difficult to conceptually digest the proposed solution. One of my co-workers pointed out an (imho) another possible alternative. It seems that the implemening multiple WorkbenchPages is exactly what we are looking for, and conceptually, froma OO design/analysis pov makes a lot more sense. However, there is no way to explicitly specify multiple pages, however, the workbench dfintiion does allow this. Are there any plans to expose this functionality (specify multiple pages)?
Dennis, re multiple pages AFAIK eclipse used to support multiple workbench pages per window. They were used for perspective switching. But they had a number of performant and usability problems, so much so that they were disabled and the current perspective management code was introduced (I think in the 3.0 timeframe). They would not be re-introduced. For activities, check out WorkbenchActivityHelper#filterItem(*) and its uses throughout the workbench code (CTRL+ALT+H). One possible path suggests that the EditorStack be able to filter out open editors, making them appear or disappear as activity enablement changes. This seems to be pointing towards manipulating how the EditorStack and EditorPane interact. The EditorStack would have to be able to manage only those editors that are currently not filtered. Issues to be solve: 1) when an activity becomes enabled/disabled, the visible editors might have to change 2) If your open editor is not visible (because it has been filtered) it should not appear in the history or MRU list (like CTRL+F6 or CTRL+E) Someone suggested having one EditorStack per perspective (it would still have to respect the dynamic addition/removal). But there you have a multi-stack maintenance problem as well. ex: opening an editor means it should show up in all open editor stacks (that it's not filtered from). There are other aspects of Editor Management (like the MRU list) that aren't managed from the presentation interaction layer, EditorStack, but are other places in the workbench, window, and page. Later, PW
Paul, is the 1 to many relationship of a WorkbenchWindow to many WorkbenchPages going to be phased out?(though only practiced as 1 to 1). Or is it the case that there are no plans to promote the WorkbenchPage out of the internal package in ui.workbench? If it isn't going to be phased out and just stagnant in the internal pkg, then perhaps we can still work with something like that. I've explored the alternatives that you have suggested in this thread but have not seen anything too promising. The page concept, or even just allocating an EditorStack per perspective is the closest thing to a solution. imho, as an RCP there should be options for this behavior at the Page layer. The current lack of options severely limits the application of the RCP to inherit this 'IDE' specific behavior. It is the IDE that should be extending the RCP, and not the other way around. Though, I can recognize that the current state of things reflects the actual chronological history.
(In reply to comment #24) > Paul, > > is the 1 to many relationship of a WorkbenchWindow to many WorkbenchPages going > to be phased out?(though only practiced as 1 to 1). Or is it the case that > there are no plans to promote the WorkbenchPage out of the internal package in > ui.workbench? We are looking at improvements to the internal model that might remove the workbench page as superfluous (of course we would still have to provide a communcation link through IWorkbenchPage, but that could be provided by the WorkbenchWindow itself). > I've explored the alternatives that you have suggested in this thread but have > not seen anything too promising. The page concept, or even just allocating an > EditorStack per perspective is the closest thing to a solution. Maybe it would be a good idea to pursue the EditorStack per perspective route. There are some editor management issues that have to be overcome, but they would be problems no matter which route we take. At the very least, the perspectives already manage hiding and restoring ViewStacks ... so making things appear and disappear as you check perspectives is handled. We had hoped to look at the "presentation" API and see if we could make it more flexible. That would allow a presentation to manage the layout data for all the views and editors, and the workbench would be responsible for part lifecycle. But it doesn't look like we'll get to it in 3.3 PW
Hi Paul, If current design improvements obviate the need for the page, then my response to this is that, precisely this bug gives the WorkbenchPage a new meaning to life. You mention that all solutions to this bug inevitabely must refine the Editormanagers' responsibilities, however, if we delegate this perspective-editor logic at the WBPage layer, then each page will have it's own set of editors, views, and therefore EditorManager and EditorStack. essentially, what happens then is, the WBPage *is* the Perspective--problem solved. If this is seen as dangerous to expose in the context of the IDE, then perhaps this can be a declaratively configurable deployment option. it seems that this was the original design intent of the WBPage, but then Perspectives came along, and somehow it was determined that the eclipse landscape was big enough for only one of them. If this is not the case, please educate me as to why the Page is being dropped and why it does not fit the bill for this bug. thx-Dennis
Paul - is the Workbench Page really going to be phased out? I need to know b/c the work around patch that we have implemented in org.eclipse.ui.workbench plugin incorporates and depends on the page structure --(ie. a wb page per perspective)-- Dennis (In reply to comment #25) > (In reply to comment #24) > > Paul, > > > > is the 1 to many relationship of a WorkbenchWindow to many WorkbenchPages going > > to be phased out?(though only practiced as 1 to 1). Or is it the case that > > there are no plans to promote the WorkbenchPage out of the internal package in > > ui.workbench? > > We are looking at improvements to the internal model that might remove the > workbench page as superfluous (of course we would still have to provide a > communcation link through IWorkbenchPage, but that could be provided by the > WorkbenchWindow itself). > > > > I've explored the alternatives that you have suggested in this thread but have > > not seen anything too promising. The page concept, or even just allocating an > > EditorStack per perspective is the closest thing to a solution. > > Maybe it would be a good idea to pursue the EditorStack per perspective route. > There are some editor management issues that have to be overcome, but they > would be problems no matter which route we take. At the very least, the > perspectives already manage hiding and restoring ViewStacks ... so making > things appear and disappear as you check perspectives is handled. > > We had hoped to look at the "presentation" API and see if we could make it more > flexible. That would allow a presentation to manage the layout data for all > the views and editors, and the workbench would be responsible for part > lifecycle. But it doesn't look like we'll get to it in 3.3 > > PW >
(In reply to comment #27) > Paul - > > is the Workbench Page really going to be phased out? I need to know b/c the > work around patch that we have implemented in org.eclipse.ui.workbench plugin > incorporates and depends on the page structure --(ie. a wb page per > perspective)-- Definitely *not* in 3.3 (Jun 2007). We won't even be doing the investigation about internal model improvements until summer 2007. If I do find out anything, I will post to this bug. PW
*** Bug 18460 has been marked as a duplicate of this bug. ***
*** Bug 147827 has been marked as a duplicate of this bug. ***
*** Bug 201057 has been marked as a duplicate of this bug. ***
I have a similar need for restricting editors in a perspective. I do have a couple of thoughts based on what I have read here. 1. Control of the editor should not be implemented via activities. I am hoping to use activities to control access to my RCP application based on a user role (which I believe is analogous to letting the user turn off UI elements themselves in the Eclipse IDE). I think that using activities at the top level (for roles) and then dynamically (for editors) will inevitably cause conflicts with defining activities and be a maintenance headache. I don't have a use case here, just a bad feeling. 2. Perhaps a widget could be added to the local editor toolbar that lets the user filter/unfilter the editor list. The widget itself might be optional depending on the application needs. 3. What happens when the user attempts to open an editor in the wrong perspective? This could be because the user has opened a view in an unusual perspective, or used a menu item or something. Does it make sense to differentiate between switching perspectives (apply the filter on the switch) and a user operation (open up whatever editor the user requests, don't apply the filter again)? Or is it the job of the application to prevent this state from being reached?
A proposed solution for this bug would be to add 2 methods to IWorkbenchPage (name to be chosen): removeEditor(IEditorReference ref) addEditor(IEditorReference ref) Removing an editor reference would remove it from the activation list and part list, but not dispose it. It could then be added back. A preliminary "guess" at the implementation could look something like: public void addEditor(IEditorReference ref) { editorPresentation.addEditor((EditorReference) ref, ""); //$NON-NLS-1$ } public void removeEditor(IEditorReference ref) { editorPresentation.closeEditor(ref); activationList.remove(ref); updateActivePart(); partList.removePart((WorkbenchPartReference)ref); } There might need to be parallel paths added, however, since this code disables some actions in the re-added editor like Undo Then RCP apps would be free to remove specific editors and add them back on perspective changes. Or the activities API could be used. This feature will not be worked on in 3.4, but I would consider patches up to M6 (realistically, about March 20th) if anyone is interested. PW
(In reply to comment #33) Thanks for the post, I'd be definitely interested in such a feature. I guess an equivalent of IWorkbenchPage.getEditorReferences() for visible editors and a way to find if an editor is currently visible will be needful too. However, I suppose this is not the final solution of the feature, I'd expect it to be more built-in and declarative (i.e. using extension point). This design requires a custom editor manager in the RCP app that handles editor visibility, which IMHO should be taken care of by the workbench. > A proposed solution for this bug would be to add 2 methods to IWorkbenchPage > (name to be chosen): > > removeEditor(IEditorReference ref) > addEditor(IEditorReference ref)
(In reply to comment #34) > However, I suppose this is not the final solution of the feature, I'd expect it > to be more built-in and declarative (i.e. using extension point). This design > requires a custom editor manager in the RCP app that handles editor visibility, > which IMHO should be taken care of by the workbench. This is what we won't be getting into. i.e. providing an API solution to manage the "when". An RCP app doesn't need to have a complex manage, it can be as simple as an IPerspectiveListener with a simple ArrayList or as complex as tying the editor type ID to the activities/capability support. I wouldn't preclude moving some contributed "Visibility Manager" into the workbench at some time in the future. So far there are no patches to consider to M6, so this will likely get deferred until 3.5 PW
Please note that (almost) all the relevant aspects of editors can be emulated in RCP applications using the ISaveablePart interface for views, the allowMultiple attribute of the views extension point and a simple map from your domain objects to the IViewReferences. This way you can put whatever view in whatever perspective where-ever you want it... After several months of boxing with the editor list code of org.eclipse.ui, I have started to use just views - and surprise - it works perfectly. As long as you don't need the navigator - which is very often the case in an RCP application - then you really can do everything with views and then some more. The major advantage as seen by me, is the ability to stack view and editor functionality in the same folder in the workbench! For reference, making a view part implement the ISaveablePart interface, means the view will have the save life-cycle as an editor part with isDirty(), doSave(..), etc management!
(In reply to comment #36) Thanks for the tip to ISaveablePart interface! Except for that, views with allowMultiple attribute is our temporary solution as well. Looks like we got to live with that :). On the other hand, the ability to stack documents and helper views in the same folder adds complexity to the UI. While it is a flexible and useful feature for a power user (which most developers are), in my experience it mostly increases confusion by regular non-tech users. But it is not a major issue, I guess.
(In reply to comment #37) In many RCP based applications, you really don't want the end-user to make too many changes to the UI layout. In one case with a banking application, we have a stack of views in a perspective that represent many different aspects of a specific customer. Some of these views are editable and some are not. E.g. the view with the base information about a customer (name, address, etc) is normally r/o, but when you want to change the information, you really want to do that in-place. For that the user must press a button, confirm the intension (in this case), make the changes and press save. It all happens in the same view, which basically changes the r/o state of several of the fields (and mutates other fields from simple Text to Combo). We really want to make sure the dirty state is managed properly, so the user don't inadequately close the window or view and for this the ISaveablePart is perfect.
Created attachment 90817 [details] Hide Editors in a page v01 This avoids the part-added/part-removed events, and simply removes the editor from the presentation and the activation list. It seems Undo/Redo continue to work. PW
Created attachment 90818 [details] Example project using an IPerpsectiveListener
(In reply to comment #39) > Created an attachment (id=90817) [details] > Hide Editors in a page v01 There seems to be a bug with how its handling "identical" editors. 1. Start Eclipse. Open the 'Java' perspective. 2. Open a Java file. 3. Create another editor by bringing up the tab's context menu and then selecting 'New Editor'. Now you have two editors on that one Java file. 4. Switch perspectives. 5. Java editors are closed as expected. 6. Switch back to the 'Java' perspective, both editors show up as expected. 7. Close the second one. 8. Switch perspectives. 9. The one editor is closed as expected. 10. Switch back to the 'Java' perspective. 11. See two editors (when we should only see one) with the second one having errors. 7. Close the first one. 8. Switch perspectives. 9. The one editor is closed as expected. 10. Switch back to the 'Java' perspective. 11. See one erroneous editor. The screen is malformed (on Linux/gtk+ anyway).
(In reply to comment #41) > (In reply to comment #39) > > Created an attachment (id=90817) [details] [details] > > Hide Editors in a page v01 > > There seems to be a bug with how its handling "identical" editors. Scratch that, this seems to be a bug with the test project in comment 40 as it just keeps stacking up editor references while never actually removing them.
Created attachment 91093 [details] Updated example project to bypass the bug described by comment 41. One problem I've found is that dirty editors that have been "hidden by the perspective" are "lost" during workbench shutdown. So if you modify a Java file and then switch perspectives and shutdown Eclipse, you won't get the notification about an unsaved modified file. It'd be great if other people can also try the patch out so that we can uncover more bugs and improve on the patch.
Anything happening here?
This would essentially mean that we would associate an 'editor filter' with a perspective. However we'd either need some sort of 'preference' (ugh!) to control whether the filter is active (if, for example, the definers of the perspective pre-define a filter) or the user will have to specifically 'opt in' by setting the filter on their perspective. This overlaps some of the stuff that Kevin and I have been going over. We're basically questioning whether or not our current 'perspective' approach is really what we want or if we'd be better of with a 'workflow' oriented approach.
is there any workaround available for this. I'm using eclipse 3.4
(In reply to comment #46) > is there any workaround available for this. > I'm using eclipse 3.4 No. We have a prototype https://bugs.eclipse.org/bugs/attachment.cgi?id=91093 but it still has some problems, see comment #43 PW
Let's see if this is do-able in 3.5 M3. PW
(In reply to comment #47) > No. We have a prototype https://bugs.eclipse.org/bugs/attachment.cgi?id=91093 > but it still has some problems, see comment #43 I was playing around with this some more last night and noticed another problem. If I open the Java editor with the 'Outline' and 'Templates' view open, they're populated with Java content and all that good stuff. If I then switch to the 'Resource' perspective, my editor is hidden (and of course, with no other editors open) but the two views still have their original Java content.
Created attachment 114340 [details] Hide Editors in a page v02 Don't lose a hidden editor during save operations. PW
Created attachment 114456 [details] Hide Editors in a page v03 Added the start of some tests to capture the usecases. PW
(In reply to comment #49) Another item on the list of "things that don't realize the editor is gone" is the Eclipse window's title text. After switching to the 'Resource' perspective, the window still has the name of the Java file that is now hidden.
Created attachment 115768 [details] Hide Editors in a page v04 I've added some more doc and some more tests. Remy, I added org.eclipse.ui.tests.api.IWorkbenchPageTest.testOpenAndHideEditor5() to test your comment #49 although I now see I have the 2 to 1 editor case and not the 1 to 0 editor case. I'll have to add a test...6() PW
Created attachment 115830 [details] Hide Editors in a page v05 I've updated the method names to hideEditor(*)/showEditor(*), and added little usecase descriptions to the tests. I've updated PageBookView so that it respects when the contributing part is hidden, and IDEWorkbenchWindowAdvisor to update the title when the last editor is hidden. PW
In reply to comment #54) > I've updated PageBookView so that it respects when the contributing part is > hidden, and IDEWorkbenchWindowAdvisor to update the title when the last editor > is hidden. Thanks Paul, from my preliminary testing, comment 49 and comment 52 appears to be covered. I wiped my original IWPT launch configuration and allowed PDE to regenerate one and it goes 68/68. However, I appear to be getting intermitten problems with 5-8 with Windows opening the file with Notepad and telling me it can't find the file. I haven't even begun to examine the tests but suspect it may have to do with the clean-up process as I've seen similar discrepancies between Windows and Linux where the resources API fails to delete things because the OS still has a lock on the files and/or folders. Also, I'm seeing a change in behaviour now with the editor area and the workbench window's title bar. I20081007-1600 (Default / Classic presentation): 1. Open one editor. 2. Editor title is at the top. 3. Minimize the editor area. 4. Editor title is still at the top (is this intended?). 5. Restore the editor area. 6. Editor title is still at the top (surprise, surprise). I20081007-1600 + HEAD + attachment 115830 [details] (Default / Classic presentation): 1. Open one editor. 2. Editor title is at the top. 3. Minimize the editor area. 4. Editor title goes away. 5. Restore the editor area. 6. Editor title does not come back (oh nose).
Created attachment 115974 [details] Hide Editors in a page v06 OK, I've updated some documents and added a test for Undo enabled state. The general usecase for this API is: hideEditor(ref) - it will hide the editor, remove it from the part list, and make the tab disappear. It fires the partHidden event when the visible editor is hidden. A hidden editor will still be part of the save cycle if you close all editors. You can also close a hidden editor, there is a test for this that passes but I don't believe the close works correctly ATM. There need to be some tests to verify part events when the editor that is not on top is hidden. showEditor(ref) - it will show a previously hidden editor, add it back to the part list, and make the tab re-appear. It fires the partVisible event. The editor should be back to normal at this point. This is the API that will be published in M3. Anybody that is interested in this functionality needs to adopt this, work on your usecases, and either comment on this bug (i.e. usecases not considered) or open new bugs and reference them here (behaviour that flat out doesn't work). If we can refine this API and get most of the satisfactory behaviour in M4 we'll continue to polish this in M5. If there is not enough feedback/adoption, I'll have to pull this functionality. Other functionality that needs to be included, but will be added in M4. 1) When you show the editor, it is added to the tab order as if you have just added a part. Should we consider putting a "failfast placeholder" in so it goes back to where it was? 2) What happens to the MRU and History when we yank out editors? I think this won't work correctly by default, but the actual behaviour needs to be nailed down. 3) make sure the closing a hidden editor works the same as closing a non-visible editor. 4) I've added a partial fix for the min/max case, but it's not effective. PW
FYI, those using the approach suggested by comment 36 (multi-instance views with ISaveablePart) may also be interested in bug 251912.
(In reply to comment #56) > Created an attachment (id=115974) [details] > Hide Editors in a page v06 Released to HEAD >20081024 for feedback PW
I'd like to describe the goals of this feature in the language of task analysis, to guide the development of specific use cases. The Workbench concept is designed to support an application where the GUI has a central focus on editors, and views are auxiliary to those editors. Perspectives present a set of views that are appropriate for a specific work context. However, the current system permits a kind of "bleed-through" of editors from one context into all others. Unfortunately, there is a complex overlapping relationship between these work contexts, so that sometimes this is exactly the desired behavior. For example, Java editing and Java debugging are different work contexts, but they are strongly related and mostly use the same editor types. This is may or may not be the case for Java editing and BIRT report design or mobile C++ development. The current global editor stack represents one policy choice: all editors everywhere. The all-views approach used by some RCP apps (comment 36) represents another: distinct "editors" in each perspective. One advantage of the all-views design is that it can gracefully move towards more reuse between perspectives. IWorkbenchPage.showView() allows client code to put the same view in more than one perspective explicitly. This lets the policy drift towards a different compromise, perhaps even going all the way to the all-"editors"-everywhere extreme. However, there is still a strong bias in the API towards separating views on different perspectives. The proposed API here provides a similar flexibility for the policy applied to editors. It allows a designer to start with the everywhere policy by default and progressively back away towards more separation between work contexts, where work context is essentially == perspective. Again, it would be possible to move all the way to the opposite extreme, with completely distinct editors on each perspective. I think there is a critical distinction between the showView() API and the hideEditor() API as currently proposed. A call to showView() declares a persistent intention with respect to the current perspective, and the Workbench is expected to maintain that intention over time as the user changes perspectives. The proposed hideEditor() API is independent of the current perspective, so that client code must be involved in the process of changing perspectives. IMHO, these two pairs of methods (show-/hide- View/Editor) should perform symmetrical functions for the sake of consistency. P.S. Besides the obvious distinction in the API for viewId vs. EditorInput, there are two more UI policy implications for the choice of view vs. editor. 1. When the Close action is used on a view, this only removes the view from the current perspective. The view itself is not closed until it is no longer visible on any perspective. With the current policy for managing editors, this distinction does not exist -- using the Close action in one perspective trivially means that the editor is removed from all perspectives. I think it is reasonable to make a distinction on this point between views and editors. Closing an editor anywhere should close it everywhere. This is a healthy bias towards the default policy, and IMHO it doesn't restrict the UI design possibilities very much. 2. In addition to maintaining the same set of visible editors between perspectives, the current policy maintains the arrangement of the special editor stack area. If that area is divided into two separate stacks in the Java perspective, this change is also applied to the Debug perspective etc. This policy is reasonable when the set of editors is mostly stable, but it starts to break down as the sets become more disjoint. You may end up with vestigial empty stacks as you move between perspectives. Again, I think this is a reasonable bias towards the most common case where editors are mostly consistent between perspectives.
(In reply to comment #59) > I think there is a critical distinction between the showView() API and the > hideEditor() API as currently proposed. A call to showView() declares a > persistent intention with respect to the current perspective, and the Workbench > is expected to maintain that intention over time as the user changes > perspectives. The proposed hideEditor() API is independent of the current > perspective, so that client code must be involved in the process of changing > perspectives. IMHO, these two pairs of methods (show-/hide- View/Editor) > should perform symmetrical functions for the sake of consistency. Just to be clear, this is something we're deliberately not supporting. Re-architecturing editors to work similar to views can be examined during the e4 work, but is impossible on the 3.x codebase. This is a final "can we do anything simple to enable some of the common RCP usecases" kick at the can, before this bug gets moved to e4/4.0. > 2. In addition to maintaining the same set of visible editors between > perspectives, the current policy maintains the arrangement of the special > editor stack area. If that area is divided into two separate stacks in the > Java perspective, this change is also applied to the Debug perspective etc. > This policy is reasonable when the set of editors is mostly stable, but it > starts to break down as the sets become more disjoint. You may end up with > vestigial empty stacks as you move between perspectives. Again, I think this > is a reasonable bias towards the most common case where editors are mostly > consistent between perspectives. The multi-stack case won't likely be supported above and beyond the guarantee we won't throw errors or kill your workbench, and empty stacks should go away. PW
I don't think any "re-architecturing" is necessary. Given the functionality proposed here -- the ability to hide and show editors globally -- it would be straightforward to track the set of hidden editors in the Perspective class and hide/show them during onActivate(). The set of hidden editors could even be persisted and restored across workbench shutdown if they are stored as IEditorReferences. I do NOT propose that the Platform should implement a policy for when hideEditor() should be called. That should be left to the client code. I am just proposing that the semantics of hideEditor() should respect the concept of perspectives. This provides a more appropriate primitive action upon which various policies can be implemented. I believe that this proposal aligns the API with RCP use cases better than a global approach, but I can only speak for the applications I've designed. Points 1 and 2 in my earlier comment justify why no other work is necessary. It makes sense to treat editors differently than views in these circumstances, so we don't have to do anything else to unify them.
Moving to M4 for the feedback phase. PW
Paul, I'm seeing a problem with the 'Outline' view on I20081112-1200. I guess this might've been caused by the changes to this bug? 1. Open a file that supports the 'Outline' view (like a Java file). 2. Open/Activate the 'Outline' view. It should render the outline appropriately. 3. Open/Activate another view. 4. Invoke Ctrl+M to maximize that view. 5. Invoke Ctrl+M to unzoom. 6. Notice that the 'Outline' view now has no content. This problem does _not_ occur on 3.4.0. If you don't think it's caused by the changes that were introduced by caused by attachment 115974 [details], I'll file another bug.
Hi Paul, This is a great feature and I think I will find this really useful. I have implemented this in an RCP app and everything seems to be working nicely. I simply have a global perspective listener that manages the hide/show editor functionality and each perspective knows what types of editors it should show. Many thanks for doing this. Cheers, Paul
(In reply to comment #63) Same problem with the 'Templates' view. The content of these two views also disappear if you maximize the view itself (whereas they were persistent on 3.4.0).
Paul, come see me when you get to this. It's almost certainly caused by the code that 'minimizes' the editor area when the view is maximized.
(In reply to comment #65) This is on I20081202-1812. 1. Open a Java file. 2. Open the 'Outline' and 'Templates' view. They should have some content. 3. Minimize the editor area, the two views go blank. 4. Restore the editor area, the two views are still blank. 5. Click in the editor to activate it. The two views' contents are restored. On 3.4.0, both views still had their content in steps 3 and 4. I suspect this to also be caused by the minimization code per Eric's comment 66. Of course, it is a little questionable as to how useful the content is when the editor has been minimized in step 3 but I think we'd all expect the content to come back when the editor's restored in step 4.
That sounds right to me; when the Editor Area is minimized there should likely be -no- active editor (we have no place to show the user editor changes) but it should certainly restore the active editor state when it's restored to the layout.
I have to implement this functionnality for my customers needs. I would like to kow if I should wait (the release feature has been postponed many times). If not, could you tell me where I can find some sample code that could be close to the implementation you choose. If I do it myself I want to be as close as possible to standard solution. Thanks in advance...
We'll need to close on this in M6 or remove the API. PW
(In reply to comment #70) > We'll need to close on this in M6 or remove the API. > > PW > I would really like to see this feature in 3.5. I have used it in a development version of an RCP app and it does a great job of making the UI a lot less confusing where people would have editor types open in perspectives that do not really 'work' with those editors. Cheers, Paul
I've released this as API >20090306 I've opened bugs for 4 known issues: bug 267420 bug 267422 bug 267424 bug 267425 PW
In I20090310-0100 PW
*** Bug 412307 has been marked as a duplicate of this bug. ***
