Bug 411611 - [Palettes] Possibility to dynamically adapt the palette
Summary: [Palettes] Possibility to dynamically adapt the palette
Status: ASSIGNED
Alias: None
Product: Papyrus
Classification: Modeling
Component: Diagram (show other bugs)
Version: 0.10.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Remi Schnekenburger CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-25 10:53 EDT by Leila Azari CLA
Modified: 2017-08-03 04:54 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leila Azari CLA 2013-06-25 10:53:09 EDT
In an attempt to support the developer with a domain specific modeling support I would like to create a palette based on a meta model for a specific domain.

The palette tools under each drawer should be dynamically changed based on selected model and active fraction of it and of course as usual, depending on the diagram type(For each model there is a governing architecture meta model which describes the domain and architectural rules).

To do this, we would need an API in order to dynamically create and customize drawers and their contents in the palette in Papyrus. Or is this already available?
Comment 1 Remi Schnekenburger CLA 2013-07-04 06:22:44 EDT
All the palette framework relies on the GMF runtime palette support (see the GMF documentation for the extension point description)

Papyrus provides a PapyrusPaletteService (on the o.e.p.uml.diagram.common plugin). This service is in charge of retrieving the active palette providers and in charge to refresh the palette content. 
There are currently already existing examples of dynamically adapting the palette with profile application/unapplication.

The principle here is to have several palette extensions, and to select which one is visible or not given the current selection/editor/etc. 
I would: 
1. Add a listener on selection, to react to selection modifications
2. Add your palette extensions in your plugin.xml (see in the gmf documentation to see how you can declare tools in one extension and then reuse them in other extension points)
3. I would let the selection listener or any other listener update palette contribution visibilities using org.eclipse.papyrus.uml.diagram.common.part.PapyrusPalettePreferences.changePaletteVisibility(String, String, boolean)

Hope this helps!
Comment 2 Toni Siljamäki CLA 2013-10-08 10:56:52 EDT
Just interested in how this discussion evolves. :)
Comment 3 Laurent Wouters CLA 2014-03-20 06:16:01 EDT
Since f515b310417b386c79d9fbd2500c5373a7179aa7 it is possible to define new kinds of diagrams on top of the existing "hard-coded" diagrams in Papyrus in a model-based fashion. These new diagrams can be attributed specific palettes.

It is also possible with the same mechanism to contribute new palettes to existing diagrams under specific condition on the owner and/or root element of the diagrams. For example you can specify a special palette to the Component diagram in the case its root is a Package (or a Component) with a given stereotype, or an given profile is applied on the model, etc.

All of this is done through the specification of a viewpoint.
You can see the specification of the default viewpoint in "plugins\infra\viewpoints\org.eclipse.papyrus.infra.viewpoints.policy\builtin\default.configuration".
There is also an example of the definition of an extension to the default viewpoint in "C:\cygwin\home\LW238780\papyrus\extraplugins\robotml\org.eclipse.papyrus.robotml.diagram.common\viewpoints\robotml.configuration"