| Summary: | [General] Navigation and integration with the creation diagram service | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Mathieu Velten <mathieu.velten> | ||||||
| Component: | Core | Assignee: | Mathieu Velten <mathieu.velten> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | sebastien.gerard, vincent.lorenzo | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 336204 | ||||||||
| Bug Blocks: | 334984 | ||||||||
| Attachments: |
|
||||||||
|
Description
Mathieu Velten
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. |