Community
Participate
Working Groups
It should be possible to locally define a palette. This palette should not be embedded in a plugin, it is just a on-the-fly defined palette. This could be using a XML file. this file could be stored anywhere on the disk or memory. The palette provide has to read this configuration and buidl the palette according to this definition Once it has been defined, it could be stored (where?), it could be exchange with other people (import/export).
Possibility to use currently a new extension point, which simply indicates the name of the palette and where the definition is. the xml file could be stored anywhere.
why claiming that the palette should not be embedded in a plug-in? One of the tool requirements is to support a MBSE process. In industry especially, process is defined by a specific team (methods team) and then applied to all projects. If we think about the palette as a means to fulfill a given process activity, we understand that palette customization is done preferably by the "methods" team and must then be applied to all projects with limited possibilities to change it. For that common situation the plug-in mechanism is a good solution to customize the palette at one place and ensure that it will remain restricted in all projects. In TOPCASED, this feature has been requested by several industrials and this is the plug-in mechanism that has been decided as the best answer. There is probably situations for both needs : local customization and "tool level" (plug-in) customization.
(In reply to comment #2) > why claiming that the palette should not be embedded in a plug-in? > One of the tool requirements is to support a MBSE process. In industry > especially, process is defined by a specific team (methods team) and then > applied to all projects. If we think about the palette as a means to fulfill a > given process activity, we understand that palette customization is done > preferably by the "methods" team and must then be applied to all projects with > limited possibilities to change it. For that common situation the plug-in > mechanism is a good solution to customize the palette at one place and ensure > that it will remain restricted in all projects. > In TOPCASED, this feature has been requested by several industrials and this is > the plug-in mechanism that has been decided as the best answer. > There is probably situations for both needs : local customization and "tool > level" (plug-in) customization. The standard extension point is still usable, and recommended of course in case of development by method team. Both way are valid : - extension point - local palettes For example, Papyrus diagram editors provide a "standard" palette, which use the palette gmf extension point.
