Community
Participate
Working Groups
Valid for profile-based DSL's and their customized palettes. When editing a model in one profile-based-DSL, and switching between different-DSL-model-parts in our "grand" and integrated system models, as a user you do not expect to see customized-palettes-noise from any other DSL than the ones customized for the DSL-model you are currently viewing/editing. The Papyrus UI should automatically adapt itself to the DS-model being opened, wrt the palettes that gets available to the user in different diagrams. (= automatically based on the profiles that defines the DSL) So... The extension point for customized DSL palettes must be extended to also include the "required profiles" parameter for deployed DSL’s. ...just like the "required profiles" parameter for locally defined palettes, defined as "workspace palettes", which works just fine.
You may be interested to know that the Diagram Assistants (bug 451230) generated for a profile are context-sensitive: by default, they are shown only on elements that are contained within a package that has the source profile applied. But, the assistants model can be edited to change where assistants are shown according to whatever criteria you need. See a brief demo: http://youtu.be/v-AakQ7TYHQ
Created attachment 250280 [details] PW protected test information, same PW as earlier... Thanx for the info. This UI-self-adaptation for profile-based-DSL's also need to work for DSL palettes/drawers/menues. Diagram Assistants is something completely different. I got a bit tricked by the engineering mail wrt extension point extensions and then I got confused... The strange thing is that palette.xml palettes sometime seem to work without having the "required profiles" defined anywhere!? Does the different Papyrus-palette-providers work so differently? (see attachment info) Other strange findings are: 1) component diagram palettes get displayed also in class diagrams 2) package diagram palette customization does not work at all 3) the .paletteconfiguration palette get displayed in any class/component diagr WRT the expected multi-DSL-integration in our "grand system models" this self-adaption of customized DSL UI's must work out-of-the-box. (= user friendly)
Remi: Is the solution identified/discussed a Mars API change? /Toni
PaletteConfiguration now have a new field 'requiredProfile', which leverages the usage of workspace & déployer palettes. The review addd some tests to check palette visibility according to profile applications.
(In reply to Remi Schnekenburger from comment #4) > PaletteConfiguration now have a new field 'requiredProfile', which leverages > the usage of workspace & déployer palettes. > The review addd some tests to check palette visibility according to profile > applications. Review 43879...
Remi - Wrt the new field 'requiredProfile': Earlier we discussed the difference in capabilities of the PluginPaletteProvider vs. the ExtendedPluginPaletteProvider. See example palette definitions below. *** EXAMPLE 1 *** <extension point="org.eclipse.papyrus.uml.diagram.common.paletteDefinition"> <paletteDefinition ID="com.ericsson.papyrus.mydsml.modeling.palette.componentdiagram" class="org.eclipse.papyrus.uml.diagram.common.service.PluginPaletteProvider" name="DSML Palette" path="/palettes/Palette_DSML.xml" provider="Provider Name"> <Priority name="Low"> </Priority> <editor id="org.eclipse.papyrus.uml.diagram.component"> </editor> </paletteDefinition> </extension> *** EXAMPLE 2 *** <extension point="org.eclipse.papyrus.uml.diagram.common.paletteDefinition"> <paletteDefinition ID="com.ericsson.papyrus.mydsml.modeling.menus.palettemodel" class="org.eclipse.papyrus.uml.diagram.common.service.ExtendedPluginPaletteProvider" icon="icons/palette_view.gif" name="DSML Menu Name" path="/model/DSML.paletteconfiguration" provider="Eclipse Modeling Project"> <Priority name="Medium"> </Priority> <editor id="org.eclipse.papyrus.uml.diagram.component"> </editor> </paletteDefinition> </extension> The problem here was that the customized palette defined by the DSML.paletteconfiguration was displayed in every component diagram for any DSML, including plain UML models. The explained reason was that the ExtendedPluginPaletteProvider is missing some palette-analysis capabilities that the PluginPaletteProvider has. QUESTION: Will the new field 'requiredProfile' solve this, and for both the PluginPaletteProvider and the ExtendedPluginPaletteProvider ? I did some testing, defining a new local (workspace) palette and then I deployed it through the PluginPaletteProvider. 1) I defined a new palette for a class diagram with a single class menu in it, and with no stereotype applied to the class. 2) There were no requiredProfiles defined for the palette in the org.eclipse.papyrus.uml.diagram.common.prefs 3) This palette gets displayed for any UML/DSML class diagram, both for the local palette and when deploying the palette. 4) I define a new class menu in the palette and apply a stereotype in the menu. 5) The requiredProfiles property now gets defined in the org.eclipse.papyrus.uml.diagram.common.prefs 6) The palette now gets displayed only in models having that profile applied, both for the local palette and when deploying the palette. The thing here is that in the *** EXAMPLE 1 *** above there is no requiredProfiles property defined, and it is not needed, since the PluginPaletteProvider takes care of analysing the applied stereotypes in the whole palette. RESULT: If there is a single menu in the palette which applies a stereotype to the element, then the entire palette gets available only in models having that profile applied, and without a need to define which profile that is "required". The problem with this is the 3) above, that a palette having menus which does not apply any stereotype to any element, that palette gets available in any UML/DSML model. I guess this new requiredProfiles property for deployed palettes solves this?
> Review 43879... This review adds a new set of tests related to the Palette Customization & Filters. It has been merged to master
The requiredProfiles defined for the palette in the org.eclipse.papyrus.uml.diagram.common.prefs lists all the required profiles for the palette. I guess that the new requiredProfiles in the PaletteConfiguration (Comment 4 above) will work the same way. ...or is it in the <paletteDefinition in the plugin.xml ??? QUESTION: Is it in the same way possible to define the same palette definition to be used in multiple editors?
With the new field 'requiredProfiles' in palette configuration models, you can indeed have the same behavior that you had with the previous xml palette definition, e.g. hiding the palette when the required profile is not applied on the model. Having it embedded in the file avoid the need to fill it in the extension point or for the deployment at runtime. Every needed information needed is in the model itself. To clarify: PluginPaletteProvider is for old xml definition files, so that has been not changed. The instrospection ability has been left as is, as it was already working fine. ExtendedPluginPaletteProvider is based on new paletteDefinition model, and the requiredProfile field has been added to this model. So you should have the same result for users. For the kind of editor on which the palette can be defined or not, I have unfortunately not the possibility to change the behavior of the gmf extension point: - either you choose there one editor identifier, and in this case the palette will be available only in this editor. - or you set no editor, and the palette will be provided for all editors.
Yep, works fine. :) Has been fixed for Luna and Mars, I assume, since it works for both. The menu pops up for the diagram when the profile is applied to the model, which means that this should work also when loading a profile application that has been stored in a separate file. Has the documentation been updated to include this 'requiredProfiles' property?
