Community
Participate
Working Groups
The initial goal was to implement navigation into the diagram. I then realize that it is tight to the possibility of creating a diagram upper in a hierarchy. For example to have the possibility to create an activity diagram from a UseCase you first have to create an activity, attach it to the use case and then create the diagram on this element. What I did is restrict the creation diagram service to allow the creation of a diagram only directly on his potential direct owner, for example an activity diagram can only be created on an activity. I did that in the classes which implements ICreationCondition : theses classes existed before but was not really used since the fact to authorize or not the creation of a diagram was directly mentioned in the plugin.xml Then the possibility to create a diagram (from the model explorer or using the navigation) on an element is the combination of the diagram creation service which strictly follows the spec and the possibilities of navigation which you can define independently from the diagram creation service, and which will also be used in the navigation. What is missing and will be implement ASAP is the toolbar and the Papyrus=>Diagrams menu.
Created attachment 186724 [details] Navigation specs
Implemented in r3676
toolbar and Papyrus=>Diagrams menu missing.
toolbar implemented in rev 3758
I do not agree with the provided implementation. As stated in 334984, Papyrus should use the Eclipse UI command framework, and should not provides its own framework for commands/menu/toolbar. Part of the changes should be rollback and another solution should be provided and discussed for this new feature. Actual changes should not be committed to the trunk until we all agree on the proposal.
The following has been decide (after phone call): - this feature is made of two parts: a creation filtering framework and a navigation framework - implementation of these features should be moved in a separate plugin. - the plugin is not mandatory for Papyrus to work. If the plugin is present, the new features are availables. If the plugin is not present, old behaviors are working, especially the eclipse creation diagram framework (see bug 334984). - other plugins (diagrams, modelexplorer ...) should not be aware of this plugin, as it can be absent. -- This mean that they should have no dependencies on it ! - The new plugin can still use the list of creation command data retrieved from the core (but this is discouraged: original purpose of this list is to allow the SashContainer to create a diagram, not to provide user commands). - The latest modifications done in 7.x for this feature should be rollback and moved to a new plugin asap - The actual code should not be commited to the trunk (0.8). Modifications should be done before.
Created attachment 188507 [details] project example An example on how to show/hide a menu contribution from a variable. The variable is owned by a ISourceProvider, and can be set programmatically from anywhere.
I have added a plugin example showing how we can show/hide an entire 'menu contribution' from a from a variable. The variable is owned by a ISourceProvider, and can be set programaticaly from anywhere. For example, Papyrus can provide common 'main menus' controlled by such well known variables. A plugin whishing to change the Papyrus default menu can disable them by modifying the variable. Then, it should provide its own menu to replace the disabled one. The plugin can get the declared contributions for the menu from the Eclipse extension, or maybe from the core command framework (to be tested). This could be a starting point to be able to provide the functionalities described by this bug, without being too intrusive in the Papyrus code.
(In reply to comment #8) I think it's a good idea, but how does it work, when many plugins assign opposite value to the same variable?
commit 4018 fixes 336204 and 334984. the last idea of cedric has not been implemented.
backported on trunk.
Add navigation decorator, using GMF mechanism. There is now an option to choose whether you want to display it everywhere, only on display or not at all. Some generic ui related components has been moved to ui.toolbox and factorized. CreateDiagramWithNavigationHandler has been moved from uml common to navigation so it can be used easily outside of UML. commited on rev 4706.
Navigation has been implemented (and maybe several time) since a long time now. So I set the bug as closed fixed.
