[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-papyrus.dev] Highest-priority provider in State Machine blocks customization
|
Chris, Your proposition songs good to me. We had a similar difficulty with SysML14. Nevertheless I do not know how to evaluate the impact of such change. RC3 is released So why not go on your proposition. Francois De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus Envoyé : mercredi 1 juin 2016 18:35 À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx> Objet : [mdt-papyrus.dev] Highest-priority provider in State Machine blocks customization Why does the State Machine Diagram define its custom edit-part provider at highest priority? <extension point="org.eclipse.gmf.runtime.diagram.ui.editpartProviders" id="ep-provider"> <editpartProvider class="org.eclipse.papyrus.uml.diagram.statemachine.custom.providers.CustomUMLEditPartProvider"> <Priority name="Highest”/> This makes it impossible for applications like Papyrus-RT that are building on Papyrus to customize the behaviour of this diagram in their context. The base implementation of a diagram should always use lowest priority. What would happen if I knocked this down to lowest priority before Neon RC4 (after deleting the other edit-provider that the diagram doesn’t need)? |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature