Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

Hi all,

 

The palettes defined using paletteconfiguration model also rely on the AspectUnspecifiedCreationTool. You can see for example the class org.eclipse.papyrus.uml.diagram.common.service.ExtendedPluginPaletteProvider.ExtendedPaletteFactory that creates the tool from the tool definition.

 

Regards,

Rémi

 

 

 

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

Description : PapyrusLogo_SmallFormatwww.eclipse.org/papyrus

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : jeudi 12 mars 2015 06:23
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

Hi, Benoit,

 

When I create a custom palette using the “Customize…” action in the palette’s context menu, all of the node items use the AspectUnspecifiedTypeCreationTool.

 

If custom palettes contributed by the extension point work differently, well, then I don’t know why that should be.  Best to ask someone who knows about the palette implementation in Papyrus.  :-)

 

Cheers,

 

Christian

 

 

On Thu, Mar 12, 2015 at 5:48 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:

Hi Christian,

 

Can you point me a custom palette using AspectUnspecifiedTypeCreationTool ?

(a palette using a custom element type)

 

For example this is what we expect the palette for Sysml 1.4 to look like :

 

/org.eclipse.papyrus.sysml14.diagram.blockdefinition/resources/palette/BddDiagram.paletteconfiguration:

 

    <ownedConfigurations xsi:type="paletteconfiguration:ToolConfiguration" id="org.eclipse.papyrus.sysML.Block" label="Block" description="Create a Block" >

      <icon pluginID="org.eclipse.papyrus.sysml" iconPath="icons/blocks/Block.gif"/>

      <elementDescriptors elementTypeId="org.eclipse.papyrus.SysML14.Block"/>

    </ownedConfigurations>

 

 

But we weren’t able to make it work with the current code. Did we missed something in the model ?

 

Regards,

Benoit

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : mercredi 11 mars 2015 16:37
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

Hi, Patrick,

 

I think the AspectUnspecifiedTypeCreationTool is already used by (at least some of) the Papyrus palettes to do this.

 

If you generate your element-types model based on the UML semantic element types only (not a diagram’s visual element types) then you’ll get an element-types model that looks like this:

 

    Stereotype element type (e.g., Block) specializes

 

        UML element type (e.g., Class) *

 

which I think is what you’re looking for?  So, you see, you have the power already.  But with great power comes great responsibility!

 

(sorry, I don’t know how that Spiderman reference came out)

 

Cheers,

 

Christian

 

 

On Wed, Mar 11, 2015 at 11:25 AM, TESSIER Patrick 202707 <Patrick.TESSIER@xxxxxx> wrote:

Hi Christian,

 

For the moment  I think that the mechanism could be improved.

Because I thanks that people that want to specialize palette do not want to write  

Visual stereotype element type (e.g., Block_2008) specializes  

     Stereotype element type (e.g., Block) specializes

         UML element type (e.g., Class) *

     Visual UML element type (e.g., Class_2008) specializes *

         UML element type (e.g., Class) *

I think that the user want to reference in the palette directly Stereotype element type (e.g., Block). So in our side the tool must be powerful to look for at runtime class_2008 and create directly a block with the appearance of block.

If it exist several kind appearance, papyrus must propose what kind of appearance to do want.

What do you think?

 

Patrick

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : lundi 9 mars 2015 16:14
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

Hi, Patrick,

 

A constraint may be useful in any case, but how did you end up with inconsistent visual ID hints?  If you generate an element-types model today based on a diagram-specific (visual) element types model, it doesn’t mix and match the hints in this way.  The transformation generates only specializations according to the base UML metaclass, and uses always the same hint as the parent specialization type.

 

Christian

 

 

On Mon, Mar 9, 2015 at 10:51 AM, TESSIER Patrick 202707 <Patrick.TESSIER@xxxxxx> wrote:

Ok,

I understand, we add advices ;D

 

I have test other things

Visual stereotype element type (e.g., Block_2007)  (hint 2007)specializes  

     Stereotype element type (e.g., Block) specializes

         UML element type (e.g., Class) *

     Visual UML element type (e.g., Class_2008) specializes *

         UML element type (e.g., Class) *

I create a block with the appearance of package ( hint 2007). Here the specialization to   Visual UML element type (e.g., Class_2008)  is like a key to let element type to be created into class diagram. The result seems strange, because we say that it specializes the graphical aspect of class 2008 but at the end the is the appearance of a package.

 

Maybe can we add constraint about the hint to be coherent with its specialization?

 

But if we  can do that,  what means if we specialize several graphical element types?

 

I raise these questions in order to be clear on semantic that we want to give about these specialization

Patrick

 

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : lundi 9 mars 2015 15:14
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

Hi, Patrick,

 

I'm not sure that I understand the question.  Do you mean creation of the element by a tool, or generation of the types model?  I'll answer the former.

 

Order of specialization doesn't matter.  When a tool asks to create Block_2008, the base EClass that is instantiated is Class and the Block supertype contributes advice that applies the Block stereotype. In any configuration, that advice binding will do is thing.

 

Cheers,

 

Christian 

 

 

On Mon, Mar 9, 2015 at 10:08 AM, TESSIER Patrick 202707 <Patrick.TESSIER@xxxxxx> wrote:

Hi, I have another question about this approach:

When we change the order about the specialization it runs:

 

 

Visual stereotype element type (e.g., Block_2008) specializes

     Stereotype element type (e.g., Block) specializes

         UML element type (e.g., Class) *

     Visual UML element type (e.g., Class_2008) specializes *

         UML element type (e.g., Class) *

Or

Visual stereotype element type (e.g., Block_2008) specializes

     Visual UML element type (e.g., Class_2008) specializes *

         UML element type (e.g., Class) *

     Stereotype element type (e.g., Block) specializes

         UML element type (e.g., Class) *

 

The result it create a block.

Why it create a block and  not a class in these two configuration? The order of specialization do not play a role? How it choose to create the semantic element, it use the more specific element type?

Patrick

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de TESSIER Patrick 202707
Envoyé : lundi 9 mars 2015 14:55
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

The solution that you have mentioned :

 

Visual stereotype element type (e.g., Block_2008) specializes

     Stereotype element type (e.g., Block) specializes

         UML element type (e.g., Class) *

     Visual UML element type (e.g., Class_2008) specializes *

         UML element type (e.g., Class) *

 

It runs and sounds nice, we cancapitalize on semantic of our profile, and we can choose the presentation of ours element if the diagram.

Patrick

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : lundi 9 mars 2015 14:52
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

It is worth noting, however, that the proxy element types mentioned by Patrick actually do implement something like this.  Is you generate your element types for your profile with reference to the core UML semantic types model, then the visual element types are created on the fly by the modelling assistants provider using the proxy types.  These have the dual semantic/visual heritage that you need.

 

Of course, for now it is only the modelling assistants that implement this.  I think it would be nice to have the option to generate that pattern in the models.

 

Christian 

 

 

On Mon, Mar 9, 2015 at 9:39 AM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Benoit,

 

This sounds like something I should fix/improve in the generation of element types for profiles.

 

If I understand correctly, what is generated now is something like:

 

  Visual Stereotype element type (e.g., Block_2008) specializes

     Visual UML element type (e.g., Class_2008) specializes

         UML element type  (e.g., Class) *

 

whereas what you need is

 

  Visual stereotype element type (e.g., Block_2008) specializes

     Stereotype element type (e.g., Block) specializes

         UML element type (e.g., Class) *

     Visual UML element type (e.g., Class_2008) specializes *

         UML element type (e.g., Class) *

 

(where the asterisked items are not generated but existing models that referenced are referenced by the generation process)

 

So that, in fact, the generation of element types is in two parts:  generating a semantic element types model for the profile and then, on a per-diagram-basis, generating the visual element types.  This would imply a change in the wizard to ask the user to reference two element types models, not just one:

 

  Generate a profile semantic element types model (or reference an existing one)

  Reference a diagram’s visual element types model

 

Comments?

 

Thanks,

 

Christian

 

 

On Thu, Mar 5, 2015 at 3:48 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:

Hi Önder,

 

I managed to make something works for Sysml 1.4. I followed these steps :

-        Generate the “semantic” element type

-        Generate the “graphical” element type (with hint and visual id at the end of the id)

-        Generate the palette using “graphical” element type (I had to make some change in the generator to group the graphical element by semantic)

 

ð  I can create the elements with the palette (not sure if everything is working fine)

 

It is obviously not the best solution : The “graphical” elements are using the uml “graphical” elements as specialized Types ID (and not the semantic element type created from the profile)

 

However I will stick to this solution to make a first implementation.

Then I will replace the specialized type of “graphical” element type to use the “semantic” one and make some change in the code to keep everything working.  

 

Regards,

Benoit

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de GÜRCAN Onder
Envoyé : mercredi 25 février 2015 16:08
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] [mdt-papyrus.dev] Palette Drag-and-Drop Problem

 

Hi,

 

Has anybody have any idea what can be the reason not being able to drag-and-drop an item from a palette to a diagram? I generated a palette for UML-RT (attached), it is loaded well, but I cannot drag-and-drop and there is no exception. Any ideas?

 

Thanks in advance,

 

Best,

 

Önder GÜRCAN

Research Engineer

Commission for Atomic Energy and Alternative Energies (CEA)

Direction of Technological Research (DRT)

Systems and Technology Integration Laboratory (LIST)

Software and Systems Engineering Department (DILS)

Model-driven Engineering for Embedded Systems Laboratory (LISE)

<image001.jpg>

Commissariat à l’énergie atomique et aux énergies alternatives (CEA)

Paris-Saclay Campus - Nano-INNOV | Bât. 862-PC1087 | F-91191 Gif-sur-Yvette Cedex

T. +33 (0)1 69 08 00 07  |  F. +33 (0)1 69 08 83 95  |

Onder.GURCAN@xxxxxx   |  Search Onder  |  LinkedIn  Papyrus

 

 

 

 

 

 

 


Back to the top