Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Papyrus/Neon Work Description/NewFeature/Papyrus Viewpoint Switch
Contents
Papyrus Viewpoint Switch
Overview
Provide appropriate UI that will let user switch seamlessly between viewpoints.
Requirement
| Index | Description |
|---|---|
| REQ_001 | The user must be able to switch between viewpoint while editing models with limited UI actions. |
| REQ_002 | The user must be warned when opening a model in a different viewpoint than the one it has been edited in and asked to switch to appropriate viewpoint if needed |
| REQ_003 | The situation where the required viewpoint to edit a model is not available in the setup must be handled |
| REQ_004 | The situation where multiple models are edited side by side but edited through different viewpoints must be handled |
| REQ_005 | It should be possible to ensure that a model will be created or opened with the required viewpoint (more particularly in RCP) |
| REQ_006 | In a viewpoint definition, it should be possible to import and reuse diagrams from existing viewpoints |
Proposal
1. Change the Papyrus viewpoint configuration preferences to allow selecting multiple viewpoint configurations. The Default configuration and the (viewpoint extension point) deployed configurations will be automatically added and initially selected (for discoverability). Such configurations cannot be removed but can be unselected (except for Default). In addition, local configurations can be added, edited, removed and (un)selected.
2. Local configurations can be added using different access schemes (file system, workspace, platform).
3. A 'Viewpoints Selection...' action will be contributed in multiple places in the workspace [REQ_001].
a. As a menubar action under the Papyrus menu
b. As a context menu action on the Papyrus model root.
c. As a toolbar action
4. The 'Viewpoints Selection...' action will show a dialog to switch the viewpoint of the model. The dialog shows a list of available stakeholders (in a drop-down menu) and their viewpoints (in a list box) that are available from the selected viewpoint configurations in the preferences (a button to navigate to the preferences will be provided). It will also show the currently selected viewpoint. A user can select a new viewpoint from the list by choosing the 'Select' button. When this happens, the new viewpoint becomes active and its relevant changes take place in the model's editor and the relevant views in the workspace.
5. The Papyrus DI (.di) model will have a new optional reference to a viewpoint. This optional reference can be initialized from an added page in the New Papyrus model wizard. It can also be changed by the 'Viewpoints Selection..." action in point 3 above. If the reference is unset, the model's viewpoint is assumed to be the one provided by the Default configuration. [REQ_003]
6. When a Papyrus model editor is opened (REQ_002) or receives focus (REQ_004), its model's viewpoint becomes active resulting in relevant changes to the editor and to the relevant views in the workbench. If the model's viewpoint is not resolvable, a warning will be displayed with an option to invoke the 'Viewpoints Selection...' dialog. [REQ_003]
Viewpoint Switch
Prior to Neon, The active Papyrus viewpoint in the workspace was selected in the preferences. In Neon, the active viewpoint is selected on a per model basis. The viewpoint preferences is where you choose one or more active viewpoint configurations (the platform deployed ones and/or workspace referenced ones). You can then choose a viewpoint for a given Papyrus model using its Viewpoint Selection dialog (available from the main menu, toolbar and popup menu). This is where you see the currently selected viewpoint, or choose a new one from a list of available ones (grouped by stakeholders) from the active configurations in the preferences. The selected viewpoint's name gets stored in a new object at the root of the DI resource of the model.
For Papyrus users
Out of the box in Neon, you will have the deployed viewpoint configurations (included the default configuration) activated by default. To change that, go to the Preferences->Papyrus->Viewpoint Configurations and deactivate some and activate others, including workspace referenced ones.
Older Papyrus models do not have a selected viewpoint, so the default viewpoint is assumed. To change that, use a model's Viewpoint Selection dialog.
For Papyrus Developers
A new class org.eclipse.papyrus.infra.viewpoints.preferences.ViewpointPreferncesManager has been introduced in Neon to manage all viewpoint preferences. The class's reload() API, invoked when the preferences are (re)applied, clears all related caches/registrations and reestablishes them based on the new preferences.
The org.eclipse.papyrus.infra.viewpoints.policy.PolicyChecker.getCurrent() was the API to access the currently selected viewpoint policy (configuration, viewpoint, stakeholder, etc.). Since such a policy is now per model in Neon, it has changed to the following:
org.eclipse.papyrus.infra.viewpoints.policy.PolicyChecker.getCurrent(EditingDomain)
org.eclipse.papyrus.infra.viewpoints.policy.PolicyChecker.getCurrent(ModelSet)
org.eclipse.papyrus.infra.viewpoints.policy.PolicyChecker.getCurrent(EObject)
i.e., you must pass now some context object to use to retrieve a policy that is specific to a given model (***)
To listen to changes to the selected viewpoint for a given model, you may listen to the insertion of a new org.eclipse.papyrus.infra.core.sashwindows.di.DiRoot at the root of the model's DI resource, and to changes to its org.eclipse.papyrus.infra.core.sashwindows.di.DiPackage.Literals.DI_ROOT__VIEWPOINT_ID feature.
To listen to changes to the definition of a viewpoint, you need to register a listener to the org.eclipse.papyrus.infra.viewpoints.preferences.ViewpointPreferncesManager class. The class notifies listeners when the preferences have been (re)applied, which may indicate changes to the viewpoint definition too.
Viewpoint's ElementTypeSetConfigurations
Prior to Neon, there was a disconnect between a selected viewpoint and the set of elementTypeSetConfigurations used. The latter almost always came from Papyrus's default IClientContext (or a few others like in sequence diagram) and were registered to it using the org.eclipse.papyrus.infra.types.core.elementTypeSetConfiguration extension point. As of Neon, each viewpoint also qualifies as a unique IClientContext. The registration of ElementTypeSetConfigurations to such IClientContext can either be done through the same extension point, using the viewpoint's name as clientContextId, or by directly referencing such configurations in the Viewpoint's new reference collection elementTypeSetConfigurations. This second approach is more model based and is the preferred option (***). This change enables custom editing behaviour per viewpoint.
For Papyrus Developers
The org.eclipse.papyrus.infra.types.core.elementTypeSetConfiguration extension point registers ElementTypeSetConfigurations to IClientContexts. To do things in a model based way, one may refactor existing extensions of that extension point to new extensions of the org.eclipse.papyrus.infra.viewpoints.policy.custom extension point. The latter registers deployed viewpoint configurations (or contributions to existing ones). Each such configuration would have a Viewpoint, whose name is set similar to the old extension's clientContextId, and whose elementTypeSetConfigurations collection is set to the one or more ElementTypeSetConfigurations from the old extension. Notice that contributions of viewpoints with similar names by different plugins get merged at runtime, meaning that their elementTypeSetConfigurations will be combined. This migration is optional (but recommended) as the old way is still supported.
The org.eclipse.papyrus.infra.services.edit.internal.context.TypeContext.getContext() API was used to get Papyrus's default context. It has been replaced by:
org.eclipse.papyrus.infra.services.edit.context.TypeContext.getDefaultContext()
to get the default context of Papyrus when no particular model is available
or
org.eclipse.papyrus.infra.services.edit.context.TypeContext.getContext(ModelSet)
org.eclipse.papyrus.infra.services.edit.context.TypeContext.getContext(ResourseSet)
org.eclipse.papyrus.infra.services.edit.context.TypeContext.getContext(Resource)
org.eclipse.papyrus.infra.services.edit.context.TypeContext.getContext(EObject)
to get the context of the currently selected viewpoint in a Papyrus model. When no viewpoint is selected in a model, the default client context is returned. (***)
(***) This migration was done to Papyrus's core plugins in Neon. Third party plugins may need to perform similar migration.