Community
Participate
Working Groups
There are currently a number of bugs that require decisions about editor arrangement to be made by the presentation. The current API does not allow this since presentations do not carry any persistent state. This enhancement requests that the following enhancements be added to the presentation API. 1. Presentation objects may carry persistent information, and can save and restore that information in the workbench. 2. The protocol for adding new parts to a presentation should allow the presentation to make decisions about the location of the new part, while still allowing it to determine which dragover affordance was being displayed when a part was dropped.
Created attachment 10577 [details] This patch contains the API changes for this enhancement This does not update the existing presentation code or workbench code to support the new API. If this is approved, I will make the remaining changes to hook this API up to the workbench. One suggestion: This is the new API that was discussed in the meeting on the 12th, and it will solve the problem quite well. However, my preference would be to split up IPresentationSerializer into IPresentationSaveContext and IPresentationLoadContext, and provide the IMemento through a new method on these objects. This would provide a convenient place to provide information that is only meaningful at initialization-time without making breaking changes to AbstractPresentationFactory in the future. (Lesser benefits would be that there would be fewer arguments to the factory methods and the interfaces seen by clients at any given time would be simpler).
Adding Andrew, since the R21 presentation will be affected.
I agree with Stefan... two interfaces would be preferable as it'd be clearer what the implementor would be expected to do with them in the context of the operation they are implementing.
If we can reuse existing persistance APIs rather than defining new ones, that would be best. See IPersistableElement and IElementFactory.
Okay... the patch has been committed, with 1 change. Rather than passing additional arguments to the factory methods, I have added a restoreState method to StackPresentation. This avoids breaking changes to existing presentation factories. I did not add the changes that were suggested by myself, Kim, and Nick since I wanted to stay as close as possible to the API that has already been reviewed and approved. I've updated the default presentation, R21 presentation, and Native presentation to conform to the new API, and I've updated the default presentation to persist the tab order. This has caused some minor regressions: - Serialization currently only works for views. Although the API is in place, I haven't had a chance to hook it up to editors yet, so editor order will be lost between workbench sessions (I know... it would be better if the opposite were true <g> -- I'll try to fix this tomorrow). - I haven't written any serialization code for the R21 presentation, so it will forget its tab order between sessions. (Note: The Native presentation doesn't need any serialization code, since it doesn't support dragging). - LWP will get compile errors in their addPart method, but it can be fixed trivially by changing the type of the second argument to Object and downcasting to IPresentablePart. I believe their presentation doesn't support dragging, so they shouldn't need to use the persistence API. Hanna, this should open things up enough for you to fix the editor management bugs you were working on. The presentation now has full control over tab order. Nick, I fixed the bug in NativeStackPresentation that was causing blank editors and views to appear when you switch tabs. It is now somewhat useable.
I've filed bug 62217 for the editor serialization issue and bug 62218 for the R21 presentation issue. The enhancement requested by this bug is fixed.
If presentations don't implement restoreState, what order will the parts be in? That is, does the workbench itself maintain any order for the calls to addPart?
The first time a perspective is opened, the workbench will add the parts in the same order as the parts were added in the perspective extension (that is: it will insert the tabs in the correct order the first time). Once drag/drop operations start happening or the user opens new editors/views, the order is undefined (note: the order will be consistent between sessions, but it will have not particular relation to what the user sees on their screen).
Yes, I more interested in the default order preserved between sessions. Also, what is the order of events between addPart and restoreState? On restore, is addPart called for all the parts, and then restoreState to restore their order?
No. Event ordering is like this: 1. Presentaiton constructed (no parts in the presentation) 2. If a saved state exists, restoreState is called. The presentation can choose to add any parts it previously knew about (and it can use IPresentationSerializer to access those parts). 3. addPart is called for all parts (including any parts the presentation may have added in step 2). addPart is now documented to ignore the call if an identical part already exists. This ordering means that the presentation can completely restore its state in the restoreState call.
