|
|
|
|
| Re: Put one shape above another using dnd [message #627091 is a reply to message #625845] |
Wed, 22 September 2010 20:42   |
 Romain Raugi
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi,
The interaction works nicely Tim, thanks a lot :)
Remains a little usability issue. The shape under the mouse is still
highlighted (what could suggest it can host the shape being dropped).
How can we disable this?
Regards,
Romain
Le 22/09/2010 12:37, Tim Kaiser a écrit :
> Hi Romain,
>
> now i understand what you intend.
>
> You can achieve the special behavior
> (move and drop on containershape of type Y without change of container
> for dropped shape) if you overwrite
> the DefaultShapeMoveFeature as shown below.
>
> This method normally adapts to the new container and sets the new
> coordinates relative to the container.
>
> You have to change the behavior in such a way that there happens no
> container change and that the new coordinates are set relative to the
> diagram.
>
> Clearly, you have to add a switch for the standard behavior which you
> want for type X (call super).
>
> Does it help?
>
> Best regards, Tim
>
>
> type Y move behavior implementation:
>
> @Override
> protected void internalMove(IMoveShapeContext context) {
> if (!getUserDecision()) {
> return;
> }
> Shape shapeToMove = context.getShape();
> PictogramElement[] currentSelection =
> getDiagramEditor().getSelectedPictogramElements();
> ILocation relToDia =
> Graphiti.getLayoutService().getLocationRelativeToDiagram(con
> text.getTargetContainer());
> int x = relToDia.getX() + context.getX();
> int y = relToDia.getY() + context.getY();
> if (shapeToMove.getGraphicsAlgorithm() != null) {
> Graphiti.getGaService().setLocation(shapeToMove.getGraphicsA lgorithm(),
> x, y, avoidNegativeCoordinates());
> }
> // restore selection
> getDiagramEditor().setPictogramElementsForSelection(currentS election);
> }
>
>
|
|
|
|
|
|
| Re: Put one shape above another using dnd [message #629419 is a reply to message #629217] |
Tue, 28 September 2010 08:19 |
Romain Raugi
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi Tim,
It will be fine, I will not use the provided rendering styles (although
it is nice feature).
I have registered an enhancement request some time ago related to the
opening of the framework to be able to customize the editors at the GEF
level: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325873
I reported it mainly for two reasons:
1- To program the Draw2D figures directly (I need this)
2- Maybe to add some custom interactions, but I have not a clear idea of
what I will need and can't do with the Graphiti API
Meanwhile, for 1), I discovered the IGraphicsAlgorithmRendererFactory
and the IGraphicsAlgorithmRenderer capabilities. I use them with
PlatformGraphicsAlgorithm notational objects (they are designed to be
used conjointly aren't they?). I've some refresh issues (subject of my
last posts) but it is a nice answer to my need.
To come back to the highlighting issue, for the moment I don't change my
Draw2D figures according to IVisualState changes so it is fine.
Thanks a lot Tim,
Regards,
Romain
Le 27/09/2010 15:49, Tim Kaiser a écrit :
> Hi Romain,
>
> i can reproduce it with a rendering style set.
> It is difficult to suppress the highlighting since
> this is woven into the framework rendering and interaction component.
> You would have to exchange the
> ShapeHighlightEditPolicy to achieve your ends.
> Doing this would involve touching non-public classes of the framework
> with the danger of complex side-effects.
>
> Probably it is better to tolerate the highlighting than to
> interfere with framework internals!?
>
> If you think it is important to open up the framework wrt edit policies,
> please post an enhancement request at our
> bugzilla.
>
> Best, Tim
>
|
|
|
Powered by
FUDForum. Page generated in 0.04322 seconds
] 
Search
Help
Register
Login
Home
