Bugzilla – Full Text Bug Listing
| Summary: | [api] support editor inputs that are not restored when a context is activated | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Sam Davis <sam.davis> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | shawn.minto, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | 3.7 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Sam Davis
Thanks for the bug report. Shawn investigated this and found a regression that was caused by bug 359312. I'll fix it and add a test cases for the editor restore. The fix was more involved than expected. I ended up introducing a new class ContextAwareEditorInput that allows contributions to control closing behavior on context deactivation. Task editors that do not show the active task are now flagged to be force closed to avoid tracking them in the context. Interesting. Does this mean that one could define a kind of editor that would not be restored when activating tasks? For example, could I implement an XML editor that would never be restored? (In reply to comment #3) > Interesting. Does this mean that one could define a kind of editor that would > not be restored when activating tasks? For example, could I implement an XML > editor that would never be restored? Yes, that is exactly the intended purpose of the new API. It seems wrong to me that this is done by forcing the editor to close. I would like to have an editor that stays open all the time, but I don't want it to be restored when activating a task as this creates problems (e.g. mulitple copies of the editor can be opened if its input's name has changed). The commit for this bug does not change the behavior, it merely restores the state that we had in 3.6. Your request should already be covered by IContextAwareEditor which is used to prevent editors from closing. We can discuss a more extensible implementation of the editor management for e4 but it's very unlikely that we will make any enhancements for 3.x due to the way the workbench integration works. I think it's good to provide an api that prevents adding editors to context, but not so good that it is not compatiable with the IContextAwareEditor's support for preventing editors from closing. I would like to be able to use both. Reopening to add test case. (In reply to comment #7) > I think it's good to provide an api that prevents adding editors to context, but > not so good that it is not compatiable with the IContextAwareEditor's support > for preventing editors from closing. I would like to be able to use both. I am not quite understanding the point that you are trying to make? You can use both. What is the nature of the incompatibility? What are you proposing instead? Correct me if I'm wrong, but I think that if I specify that an editor should not close and also that it should not be added to the context, only one of those things will happen (either it will close, or it will stay open and be added to the context). What I would like, and I realize this may not be possible, is to have a way of preventing editors from being added to the context without having to close them. (In reply to comment #9) > Correct me if I'm wrong, but I think that if I specify that an editor should not > close and also that it should not be added to the context, only one of those > things will happen (either it will close, or it will stay open and be added to > the context). What I would like, and I realize this may not be possible, is to > have a way of preventing editors from being added to the context without having > to close them. Yes, as far as I know we can not support this with the workbench integration that we use on 3.x. This is one of the things that we could try on 4.x which has different APIs for persisting workbench state. I have committed a test case. Steffen, you changed this to be an API request which is not fixed. You might want to either reopen it or change the summary back. org.eclipse.mylyn.context.ui.ContextAwareEditorInput was introduced to resolve this bug and hence I tagged it as [api]. As I said in comment 10, we don't have plans to support further enhancements for the editor restore API at this point. Sorry, my mistake. |