Community
Participate
Working Groups
Currently it seems that editors can only be opened (with or without activation), or get restored via mementos at workbench startup. Mylar, and potentially other tools that need to open more than one editor at once, would benefit from a mechanism to restore editor references identically to how startup does it. Opening a dozen Java editors is unecessarily slow, seems to load the outlines, etc, even when "activate" is set to false. Currently we have: IDE.openEditor(activePage, (IFile) resource, false); What I'm asking for is something like: IDE.openEditors(IWorkbenchPage page, IFile[] files) If no editor was active this would probably want to active the editor for the first file in the list, or could take a boolean to specify if that should happen. It might make sense to try this out somewhere internal before moving it to IDE, but off-hand it seems seperate from the more complicated memento support for restoring editors.
Kim, if this should go somewhere else let me know...
Will this be on the table for 3.3?
It's too early to tell - the 3.3 schedule is still being worked on.
Any news on this? It seems like a straightforward addition to Platform, but hard for others to work-around without any reasonable performance without editor mementos being exposed more. If this did not make it, shall I look into and submit an new report for exposing editor mementos so that 3rd parties can at least implement a mechanism for restoring editors?
Sorry, no news as of yet but this is an entirely reasonable request.
I doubt I'm going to have time to implement this - it'll require refactoring of WorkbenchPage and EditorManager that I don't really have time to consider right now. I'll happily entertain a patch, howeve.r
OK, I should be able to explore this mid-October. Which approach do you suggest: 1) Memento-based, e.g. using EditorManager.getMemento(IEditorReference) so that a client can store a memento and then ask the workbench to restore it. 2) Having the client create an IEditorReference and exposing a way of restoring those on EditorManager. 3) Something else?
Kim: any pointers on this? We're in the tough spot right now where activating a task in Mylar takes way longer than it needs to, and results in a bunch of flickering, because of the fact that we need to reopen each editor. The mechanism for restoring editors is already working very nicely in the workbench, so it would be great if we could reuse it somehow. And it also seems fine if we have to store the mementos ourselves, as mentioned in comment#7.
I'd lean towards option one but I am no longer component owner for Editors. Passing to Boris for comment.
I'm not an expert (yet) but it seems that EditorManager.getMemento(IEditorReference) returns a non-null memento only for editor references that were restored from a previous session but not yet materialized. For materialized editors, have a look at IEditorInput.getPersistable(), this can be used to serialize the editor input. Finally, given an editor input and an editor ID, you should be able to call IWorkbenchPage.openEditor(input, editorID, false) to open the editor without materializing it.
Thanks for the pointers Boris. Will try this approach and report back (I think it was trouble with getting something like IEditorInput.getPersistable() that stumped me previously).
(In reply to comment #10) > Finally, given an editor input and an editor ID, you should be able to call > IWorkbenchPage.openEditor(input, editorID, false) to open the editor without > materializing it. From looking at that yesterday, it seems that unfortunately, passing false does materialize the editor by showing it, it just doesn't activate it so that the currently active part (say, a view) remains the active part.
Yes, that looks like a sibling of the problem that I stated in the second paragraph of the description of this bug, i.e. using IDE.openEditor(activePage, (IFile) resource, false) was causing materialization. But in my description I was confusing activation with materialization. If that were fixed/changed/added we would have a dramatic improvement for Mylar, Open Type, and other clients needing to open more than one editor. I've been scared to go down the road of managing our own editor mementos, so it's good to see that there are now other clients needing this. I wonder if for 3.3 we could get an internal method (e.g. on Workbench) that can open a list of editors without materializing more that the first? Or a method for opening an editor without materialization (assuming 1 or more materialized editors are already open? Or a recommended idiom that clients could implement?
>I wonder if for 3.3 we could get an internal method PMC approval is requested for new feature during M7 and if this gets approved then we should add it the right way i.e. with an official API.
(In reply to comment #13) > [..] Or a method for opening an editor without materialization (assuming 1 or > more materialized editors are already open? [..] I think that would lead to confusion, since it would have to open an editor hidden and in the background, which is by itself a rather unexpected operation for the user. We really need IDE.openEditors(IWorkbenchPage page, IFile[] files), which should - open all but the last file in immaterialized editors - ensure that the tab ordering and the editor MRU stack (Ctrl+F6) behave as if the given files were opened in sequence - use a cancelable busyCursorWhile(..).
>We really need IDE.openEditors(IWorkbenchPage page, IFile[] files), which >should Of course we also need it for file stores.
Are there still chances of getting this into 3.3? If votes help make the case for the PMC I can post a link to this bug on the Mylar newsgroup, since every user of Mylar would benefit greatly from this and a number are likely to vote for it.
(In reply to comment #17) > Are there still chances of getting this into 3.3? I would say no (unfortunately), because this is not just a matter of exposing existing functionality as API - we would have to implement this *and* provide API for it. Given the complexity of the existing code, I don't see this happen for real in the remaining time for 3.3. If you had a patch for me that did not add API but somehow exposed this functionality for experimentation, I would be willing to put that in. Just don't go wild and refactor everything, it would have to be a small change (additional methods).
(In reply to comment #18) > If you had a patch for me that did not > add API but somehow exposed this functionality for experimentation, I would be > willing to put that in. Thanks Boris, I should have an answer or patch back to you in a day or two.
I explored this further and see two solutions: 1) Allow clients to restore editors via mementos 2) Provide a generic mechanism for restoring editors without materialization It seems that that the changes for (2) are out of the scope for 3.3. Currently the Workbench has no notion of having editors without an IEditorInput show up as a visible tab. I do think that this kind of lazy materialization would be valuable, e.g. for the Open Type use case (bug 178231). For (1) there is a very nice solution, make: org.eclipse.ui.internal.EditorManager.restoreEditorState(IMemento, ...) public instead of protected. This says that some clients (of EditorManager internals) know how to manage editor mementos themselves, since the Workbench's editor memento management is very limited. The change suits Mylar perfectly, since our lifecycle for restoring editors is not workbench start/close, it's task activate/deactivate. It also gives us another key thing needed restoring that (2) would not do: line locations and selections are preserved. I have this fully implemented now, the performance of context activation is an order or magnitude or two better. Below is what our client code looks like. An alternative to changing the code would be to put this method into EditorManager since it is quite similar to EditorManager.restoreState(IMemento). private void restoreEditors(WorkbenchPage page, IMemento memento) { EditorManager editorManager = page.getEditorManager(); final ArrayList visibleEditors = new ArrayList(5); final IEditorReference activeEditor[] = new IEditorReference[1]; finalMultiStatus result = new MultiStatus(PlatformUI.PLUGIN_ID, IStatus.OK, WorkbenchMessages.EditorManager_problemsRestoringEditors, null); IMemento[] editorMementos = memento.getChildren(IWorkbenchConstants.TAG_EDITOR); for (int x = 0; x < editorMementos.length; x++) { editorManager.restoreEditorState(editorMementos[x], visibleEditors, activeEditor, result); } for (int i = 0; i < visibleEditors.size(); i++) { editorManager.setVisibleEditor((IEditorReference) visibleEditors.get(i), false); } if (activeEditor[0] != null) { IWorkbenchPart editor = activeEditor[0].getPart(true); if (editor != null) { page.activate(editor); } } } Can we go ahead with (2) for 3.3? I can submit a patch but it's just a one word change.
(In reply to comment #20) > Can we go ahead with (2) for 3.3? I can submit a patch but it's just a one > word change. You meant (1), right? I released the change and made the method public in 3.3. Can you please open a new bug so that we can put real API in place for 3.4?
Boris, in my opinion this bug is not fixed, except for the special case. Most of the depending bugs cannot be fixed with the "fix" provided here.
(In reply to comment #21) > You meant (1), right? I released the change and made the method public in 3.3. > Can you please open a new bug so that we can put real API in place for 3.4? Fantastic. Yes, I meant (1). It's working beautifully and I wish I would have invested the time in figuring out that the restore could be so straightforward way back. (In reply to comment #22) > Boris, in my opinion this bug is not fixed, except for the special case. Most of > the depending bugs cannot be fixed with the "fix" provided here. I agree, as it seems that more of this bug is now about restoring editors without materialization (2) than about providing a memento-based way of restoring editors. We could change the summary to "provide API..", but I'm happy to file a new bug and move over the dependencies if that's easier, just let me know.
I would prefer a new bug for the API request.
Done: bug 183602
Verified on Windows XP using I20070503-0842.
