Bug 442145 - Provide an API to dynamically add odesign elements
Summary: Provide an API to dynamically add odesign elements
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 1.0.1   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-08-20 05:06 EDT by Christian Pontesegger CLA
Modified: 2014-11-13 12:29 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Pontesegger CLA 2014-08-20 05:06:09 EDT
Sometimes tools cannot be statically defined in the odesign file. Runtime information might add new features which require additional tools.

In a more generic form we might have additional components to draw, additional edges, ...

Provide an API to add odesign extensions at runtime. Such extensions might be real odesign files or created programmatically on demand.

I guess the odesign is an EMF model itself, right? So we could modify and extend it dynamically if we get access to it.
Comment 1 Laurent Redor CLA 2014-08-21 03:55:51 EDT
Could you detail the use case where a dynamic modification of the VSM (odesign file) would be needed?
It could be possible to handle this cases with more generic tools.

Otherwise, you can create programmatically a VSM in the workspace with the dynamical part in a diagram extension with a layer activated by default, and activate the corresponding Viewpoint programmatically. It's not necessarily simple to do ...
Comment 2 Christian Pontesegger CLA 2014-08-21 12:52:21 EDT
In my usecase I would like to populate the tools palette with elements generated dynamically via extension points. What this elements will do can be generated, but I would need to extend the viewer model.

I thought as the model is written in EMF anyway and EMF could be generated dynamically, we could also extend the view model dynamically.

If that works, it could be a generic mechanism that not only works for tools, but for any part of the view definition
Comment 3 Maxime Porhel CLA 2014-08-29 06:13:27 EDT
It seems you need a new API method in org.eclipse.sirius.diagram.ui.tools.api.graphical.edit.palette.PaletteManager to provide additional tools to the palette, or an extension point to to provide palette extensions.

For the moment, you could eventually try get the palette Viewer and add you own org.eclipse.gmf.runtime.diagram.ui.internal.services.palette.PaletteToolEntry.
Comment 4 Christian Pontesegger CLA 2014-09-02 07:44:21 EDT
(In reply to Maxime Porhel from comment #3)
> It seems you need a new API method in
> org.eclipse.sirius.diagram.ui.tools.api.graphical.edit.palette.
> PaletteManager to provide additional tools to the palette, or an extension
> point to to provide palette extensions.

An API would be preferred. For my usecase I cannot use extension points as entries are created dynamically using reflection and annotations in user contributed code.
Comment 5 Pierre-Charles David CLA 2014-10-17 05:03:50 EDT
It might be already possible to do something like this (at least if my understanding is correct) by dynamically generating/updating a VSM in the workspace for each user session (beside the .aird for example). The VSM would contain Diagram Extension Description(s) with additional tools and mappings. You should be able to use the existing extension points and listeners to ensure that:
* for all relevant sessions the Viewpoint(s) defined in this VSM is automatically enabled;
* the dynamic VSM is updated when needed (depending on semantic changes) using a pre-commit listener (see SessionEventBroker), so that when Sirius refreshed the representation it will take any changes in it into account.
Comment 6 Esteban DUGUEPEROUX CLA 2014-11-13 12:29:01 EST
It is an interesting need, unfortunately the palette is used only for tool creation and are defined statically in .odesign resource.

As Sirius is based on GMF and this last on GEF, you could use the GEF API to update the org.eclipse.gef.palette.PaletteRoot programmatically. But we can't guarantee that Sirius code will not remove your palette update then you should care of that. 

Another person has this need : https://www.eclipse.org/forums/index.php/t/852082/
In this forum discussion, the user want display model elements in the palette to use it as a library of model elements. When behind dropped in the diagram, the tool will associate an element of the diagram to the dropped model element from the palette.

To resume, the need is to have a mapping in the odesign to display instances in the palette and have actions executed when dropping model elements from the palette to the diagram. This could be a feature request for that.