Community
Participate
Working Groups
We need an implementation of shared parts: shared editors (editor areas?) between, shared views. There is an MProxyPart but it does not seem to be supported in the current implementation. The implementation of shared parts might be a good opportunity to clear the "part reference" vs "actual part" distinction.
This is an area that needs a thorough review to ensure that we get the concepts right. We will eventually want people to be able to create UI 'shapes' beyond what's possible today and need to ensure that we can handle these layouts as well (for example a person with a wide screen that wants to show two perspectives 'side by each' using a sash...).
*** Bug 283642 has been marked as a duplicate of this bug. ***
Committed in >20091126. We can now render model structures such as: Window PerspectiveStack Perspective PartSashContainer ... Perspective PartSashContainer ... Also 'augmented' the e4Photo demo to have two perspectives and a command to be able to switch between them. Still to do: make a generic trim element that manages the perspective switching implement the logic for a perspective 'switch' (firing part visible/activation events, correctly share parts...) Note that while it's not used yet there is code in the renderer that will indeed share a part if it's been created in one perspective and is visible in another. Unfortunately switching back to the previous perspective doesn't restore it (that's to be part of the perspective 'switch' logic).
After much circling we've decided to go with an approach in which people wanting to share views between different containers have to 'buy in' by using a different set of model elements to describe their structure. This makes adopting this 'advanced' feature symmetric with how we currently manage adopting the Commands framework (i.e. if you want the advanced features you have to change the model elements you use. This technique applies to -any- UIElement (i.e. it's not 'part' specific in any way). This is to allow sharing of structures like the editor area... In this case we'll introduce two new model classes: SharedElementContainer: this is a container that provides a location to put the UI Elements that are to be 'shared' so that there's only one 'real' instance of an element in the model. UIElementRef: This is a hard reference to the element that is to be shared that can be placed in the ui model at the same location that you'd ordinarily have put the element being referenced. Uses of the reference will be reference counted with the actual element being disposed when there are no more rendered instances of its references.
In some scenarios we can envision having to support in the future it may be necessary to have the references adopt more of the original element's state 'locally'. For example we may want to support locale-based perspectives. Here, the labels for the various views would be different... In these cases the approach would be to create a specific reference class that mixes in any state it wants to override (in the scenario above we'd make a new subclass of reference that also mixes in the UIItem data element).
Just got bit by this in the compatibility layer. Editors share the same id but they are not actually the same. I ended up having my second editor have the same implementation object as the first.
(In reply to comment #6) > Just got bit by this in the compatibility layer. Editors share the same id but > they are not actually the same. I ended up having my second editor have the > same implementation object as the first. In 3.x an editor is unique only by identify (IEditorReference/IEditorPart). It has specialized functions that search through existing editors by input, or by input and id :-) PW
Remy's issues may be the result of the current (and broken) implementation of 'shared parts'. The current version uses the 'id' to determine whether to share. This is incorrect and will be replaced by a more explicit mechanism; A shared part must be represented in the model as *one* real part and 'n' UIElementRef's each pointing to it.
Committed in >20100113. There is now an implementation that 'works'. The code will need a real cleaning, this was a 'just get it in' necessity due to the amount of time spent here.
Committed in >20100113. Added code to maintain the Z-order when reparenting an existing control. Without this the order of the elements in sashes was getting reversed.
Committed in >20100114. Fixed a couple of edge conditions as well as an init error in the sash handling for container data.
Committed in >20100504. Changed the model in two ways: - Added a 'sharedElements' list in MWindow. Correct uses MPlaceholder are expected to reference elements in this list. - Added a 'StackElement' containment classifier to allow PartStacks to contain both MParts and MPlaceholders.
(In reply to comment #12) > - Added a 'sharedElements' list in MWindow. Correct uses MPlaceholder are > expected to reference elements in this list. I noticed an element cannot be both a children of the window and a shared element of the window. In the latter case, getParent() returns null, is this expected?
(In reply to comment #13) > (In reply to comment #12) > > - Added a 'sharedElements' list in MWindow. Correct uses MPlaceholder are > > expected to reference elements in this list. > > I noticed an element cannot be both a children of the window and a shared > element of the window. In the latter case, getParent() returns null, is this > expected? This seems to be the expected behaviour.
Created attachment 167386 [details] Patch to provide shared editor areas while self hosting This is partly the implementation of the new shared parts story and partly changing the EPartService implementation to use it for the editor area.
Committed in >20100506. Applied the patch.
Added some code to the reconciler. At least the workbench comes back up again.
Created attachment 167567 [details] Patch to add methods in the EModelService that understand MPlaceholders
Created attachment 167575 [details] EMS and EPS patch This patch will activate editors but perspectives are bad.
Created attachment 167590 [details] Fix Bring to top to only search the current perspective
(In reply to comment #20) > Created an attachment (id=167590) [details] > Fix Bring to top to only search the current perspective Indeed. Activating editors no longer cause the perspective to switch.
(In reply to comment #20) > Created an attachment (id=167590) [details] > Fix Bring to top to only search the current perspective Views cannot be closed and reopened. When they are reopened, they do not appear to have been rendered and errors start spewing out on the console.
Committed in >20100510. Applied the patch + a change in the EMS 'bringToTop' to force the 'toBeRendered' flag to true for all elements.
Created attachment 168595 [details] Implements shared views Fairly significant update. Now all views are created as shared elements. Known Issues: There are likely going to be issues surrounding multi-instance parts (they should likely change back to non-shared parts) The DnD code is working but still has some issues related to dragging MPlaceholders.
Committed in >20100514. Applied the patch. All tests are green...
Committed in >20100514. Checked in the changes to the PartServiceImpl and EPartService. Also noticed that there are no close buttons any more for view...;-(.
Created attachment 169182 [details] Patch to allow closing/re-opening views Also fixes up the context switching...
Committed in >20100519. Applied the patch. NOTE: One consequence of this patch is that I've commented out the parts of the code that remove view references on dispose. We should get together and go over what the expected life-cycle of these are at some point.
(In reply to comment #28) > NOTE: One consequence of this patch is that I've commented out the parts of the > code that remove view references on dispose. Which dispose are we talking about here? If a view's TBR goes to false, the VR needs to go. VRs should only be there for visible tabs (visible as in rendered tabs, they might not be visible but in the chevron ;)).
Committed in >20100521. Fixed a number of issues around closing and re-opening views (as well as views like the Console that open automatically on starting an inner).
(In reply to comment #29) > If a view's TBR goes to false, the VR > needs to go. To clarify, they need to go if they're no longer in the perspective. We need a central VR cache for all views across all _opened_ perspectives in a given workbench page.
The vast majority of this work is done, any new issues should get their own defect. (yay!)
