Eclipse Community Forums: GMF (Graphical Modeling Framework) » Duplicate command drop-down when dropping nestable widget from palette

Home » Modeling » GMF (Graphical Modeling Framework) » Duplicate command drop-down when dropping nestable widget from palette(I see two identical commands in the drop-down when dropping a "nestable" widget from my palette)

Duplicate command drop-down when dropping nestable widget from palette [message #699862]

Fri, 22 July 2011 09:55

Eclipse User

Hi,
I have an ECore model with a type that may contain another object of it's own type. I got my gmfmap set up such that these elements can be nested to arbitrary depth on the canvas. The pop-up balloon let's me nest the elements to a depth of 2.

Following that I can pick and drop the element from the palette. Here is where it gets tricky, as the palette tool presents two identical options when you drop. One of them will work for nested elements. The other one works only when dropping on the canvas itself. If I pick the right one, I can nest the elements to any depth. (First option is for dropping on canvas, second is for nesting.) I'm trying to get these options to show up only in the right context, or to at least be distinct in UI. Any suggestions for where to look or what I can override?

In case it helps, the model and 2.2 mappings are here:
github.com/UNC-Libraries/Curators-Workbench/tree/master/crosswalk-gmf/model

An aside:
This model represents metadata mappings to XML elements and is used in the Curator's Workbench software here:
github.com/UNC-Libraries/Curators-Workbench
Any suggestions on this driving problem are definitely welcome. The GMF stack has been terrific for this. The intent is to enable visual programming that maps metadata migration to an XML schema.

many thanks,
Greg

Re: Duplicate command drop-down when dropping nestable widget from palette [message #701149 is a reply to message #699862]

Sun, 24 July 2011 14:11

Eclipse User

Hi,

I have no idea why it is happening.
The EditPolicy that is repsonsible for this is org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEditPolicy
It might be a good starting point to search a solution to your issue.

Let us know if you find solution and how and if you need more information that we can provide.

Hope it helps

Regards,

Re: Duplicate command drop-down when dropping nestable widget from palette [message #702587 is a reply to message #701149]

Tue, 26 July 2011 10:46

Eclipse User

I've confirmed that my class, the CrosswalkModelingAssistantProvider, only provides the MappedElement_2016. However, it looks like the nested element type, MappedElement_3015, is a specialization of MappedElement_2016. Is it possible that the specialization type is resulting in an additional creation command/tool in the drop down?

It's hard to tell if additional popupbar descriptors are being added in from outside of my model assistant provider. Hard to figure out where to put a breakpoint..

thanks for your help,
Greg

Re: Duplicate command drop-down when dropping nestable widget from palette [message #703613 is a reply to message #702587]

Wed, 27 July 2011 14:47

Eclipse User

If anyone is still following this thread, I've got some findings. For testing, I removed the PopupBarEditPolicy from my canvas edit part entirely. The diagram assistant no longer pops up on hover, so it seems to gone from my part. Yet, dropping my "XML Element" from the palette tool still presents a popup-menu with two identical choices. Only the first choice works in the canvas context, the second choice works in the nested context..

So I the problem seems unrelated to the PopupBarEditPolicy.

Greg

Re: Duplicate command drop-down when dropping nestable widget from palette [message #703680 is a reply to message #703613]

Wed, 27 July 2011 16:23

Eclipse User

Okay, more digging and I've finally found the class which refines two potential create requests into one: CreateUnspecifiedTypeRequest

This request is satisfied by the UnspecifiedTypeCreateCommand that is returned by the active CreationEditPolicy. So I suppose I could subclass the default CreationEditPolicy, intercept the call to getUnspecifiedTypeCreateCommand() and remove the offending element type from the request somehow. In theory.

Re: Duplicate command drop-down when dropping nestable widget from palette [message #708228 is a reply to message #699862]

Tue, 02 August 2011 11:39

Eclipse User

Following up on this for the archives..

My eventual solution was to subclass CreationEditPolicy. I installed instances of my subclass on the parts that can host these nested elements, the parts that present the double popup when clicked from the palette selection.

The SpecialCreationEditPolicy overrides getCommand(Request):

github.com/UNC-Libraries/Curators-Workbench/blob/master/crosswalk-gmf.diagram/src/crosswalk/diagram/custom/SpecialCreationEditPolicy.java

If the request is a CreateUnspecifiedTypeRequest and the host's semantic element is one of the expected values, then it will look for the correct underlying request. It then makes a new CreateUnspecifiedTypeRequest with only 1 request type. It calls the super.getCommand(), passing the new, refined CreateUnspecifiedTypeRequest.

I had also tried just passing the type-specific request retrieved from the original CreateUnspecifiedTypeRequest, but this produces some strange behavior in fact.

I still have a weird layout issue that probably relates to the GMF vs. GEF coordinate systems. The new elements appear in strange places when dropped on the canvas element.

[Updated on: Tue, 02 August 2011 11:41] by Moderator

Re: Duplicate command drop-down when dropping nestable widget from palette [message #876373 is a reply to message #699862]

Thu, 24 May 2012 09:27

Eclipse User

It is several months later, but I wanted to post the real reason for this issue, which I recently discovered. The problem was with unusual prompts when dropping elements from the palette onto the canvas.

I was thrown off the trail here because the problem only presented in a particular element that was nestable. Hence I thought that the creation policy was having trouble resolving the "create unspecified type request" into the right notational model, instead prompting the user.

Well, the real reason that the standard creation edit policy could not resolve the unspecified type creation request was that I had EditHelperAdvice involved. My advice on this element was returning a before and after creation command for the element in question. It was returning a command in a way that did not distinguish between the two notational models available. In other words, it returned advice even when the real "type specified" edit command was unexecutable or non-existent. This seems to have confused the edit policy enough to make it prompt the user to make the choice.

My fix was to make the creation advice sensitive to the container on offer and only return a non-null advice command result when the request is specific to the given context.

I think this is something that might be added to the edit helper advice docs. It was hard for me to make the connection between advice I thought would be discarded and the impact this had on the resolution of the creation request.

thanks,
Greg

Previous Topic:	Top level node auto-created on diagram initialization that can not be deleted later
Next Topic:	get target after creating relationship

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 08 08:59:14 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter