Bugzilla – Full Text Bug Listing
| Summary: | [e4][context] NoSuchMethodError thrown when de/activating a task | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Remy Suen <remy.suen> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | deepakazad, krzysztof.daniel, Lars.Vogel, pwebster |
| Version: | 3.6 | ||
| Target Milestone: | 3.7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 321278, 371807 | ||
|
Description
Remy Suen
Thanks Remy. That's one of the trickier problems. Shawn, I think we should fail gracefully for now and try to find a way to make editor refresh work later. What is this code trying to do exactly? On task activation it restores the editor tabs that were open on last task deactivation. (In reply to comment #3) > On task activation it restores the editor tabs that were open on last task > deactivation. I guess recording what editors were open isn't good enough because the user's cursor position in the text file is only preserved on a memento save, yes? Yes, the closer the restored workbench state is to the state on deactivation, the better. Sigh.. any chances of this getting fixed sometime soon ? Now that JDT has moved to Git, I have started to switch between bugs that I work on more often because switching a branch is inexpensive. The next logical step here is to use the Context management capabilities of Mylyn, where I mostly want the opened editors to be restored and in correct order (on 4.x the order is fixed and useful). Are there any workarounds for this bug? I don't think the files in the context, which are shown in the Package Explorer, are same as the open editors. Unfortunately there is no simple work-around since the internals that Mylyn uses to persist the editor state do not exist in e4 any longer. The editor management will need to be re-implemented for e4 and we don't have a targeted milestone for this fix, yet. We are happy to prioritize this if a fix is supported through a community contribution. *** Bug 367665 has been marked as a duplicate of this bug. *** I don't get the NoSuchMethodError error but views outside the editor area are not restored / closed. Only editors are restored on task activation. Other views or the workbench layout are not managed with task activation. Due to the changes in the workbench API editor restore is not supported on e4 at the moment. If you are interested in enhancements to editor please add your suggestions to this bug: 244075: restore dual editor panes upon task reactivation if previously working in dual pane mode https://bugs.eclipse.org/bugs/show_bug.cgi?id=244075 Remy, I took a brief look at my workspace and it looked like the .metadata/.plugins/org.eclipse.e4.workbench/deltas.xml was still being used to persist the workspace state. Can you point me at the class in e4 that handles that? I would like to investigate how we could re-implement e4 based editor restore. (In reply to comment #11) > Remy, I took a brief look at my workspace and it looked like the > .metadata/.plugins/org.eclipse.e4.workbench/deltas.xml was still being used to > persist the workspace state. Can you point me at the class in e4 that handles > that? I would like to investigate how we could re-implement e4 based editor > restore. Have a look at org.eclipse.ui.internal.EditorReference. That does the work right now to restore an editor with an IMemento (which we stash in the editor MPart model as a string). Is that what you're looking for? PW Thanks, that helps. I'll look into using IWorkbenchPage.openEditors(final IEditorInput[] inputs, final String[] editorIDs, final int matchFlags) to manage editor restore. Unfortunately it will require a bit of boiler plate code to implement persistence for inputs though. I was hoping that we might be able to capture workbench state more easily in e4 using MPart (or something like that) but I didn't find any straight forward API for that. I might try to take a first pass at editor restore using the existing API above and will consider filing a feature request for additional functionality such as persisting perspective layout. (In reply to comment #13) > Thanks, that helps. I'll look into using IWorkbenchPage.openEditors(final > IEditorInput[] inputs, final String[] editorIDs, final int matchFlags) to > manage editor restore. That wouldn't instantiate all the editors so I'm not sure if that will do what you want. It sounds to me like you want fully instantiated editors if you want to restore the states. > Unfortunately it will require a bit of boiler plate code > to implement persistence for inputs though. Yes, you'd have to use an IMemento to store both the IEditorInput and IPersistableEditor to call saveState(IMemento) and restoreState(IMemento) on. (In reply to comment #14) > (In reply to comment #13) > > Thanks, that helps. I'll look into using IWorkbenchPage.openEditors(final > > IEditorInput[] inputs, final String[] editorIDs, final int matchFlags) to > > manage editor restore. > > That wouldn't instantiate all the editors so I'm not sure if that will do what > you want. It sounds to me like you want fully instantiated editors if you want > to restore the states. That is correct. We would loose some functionality that we have in 3.x right now. The editor restore would no longer be capable of restoring the selection or any other state that IPersistableEditor stores. For performance reasons we don't want to realize all editors. We could potentially hack around this by injecting an editorState memento into the EditorReference through reflection but it wouldn't be pretty. The exception described in the description of this bug is no longer logged. Editor state that was captured while running on 3.x is retained but editor restore is no longer supported on e4. There is no obvious way to re-implement editor restore on task activation given the current APIs. I have opened bug 373098 to track that as an enhancement. Since this is key functionality I would like to resolve that for Mylyn 3.7 but we can't currently commit to that without API support in platform. |