Community
Participate
Working Groups
The interesting states during creation of a connection are - connecting - attached to source - attached to target - canceled The first state is the initial one. It should be entered when a connection tool is selected. The second state is assumed after clicking on a valid anchor. Then a feedback figure for the connection to be created is drawn. The third state is entered when a valid target anchor was clicked. The last state is entered if escape is pressed or after having clicked on an invalid target. The CreateConnectionFeature should have overridable methods that are called when either of these states are entered.
Would like to target for Juno
@Henrik: Please can you make a proposal for the method names and their parameters?
As call backs in the AbstractCreateConnectionFeature the following methods would be sufficient: - void startConnecting() - void attachedToSource(ICreateConnectionContext context) - void doneConnecting(ICreateConnectionContext context) - void abortedConnecting() The third method (doneConnecting) could be dropped since it would be called after having successfully called create(ICreateConnectionContext context). Motivation: In eTrice there are structure diagrams where ports are connected by bindings. When connecting is started I would like to highlight all ports still connectable (possible connection sources). When the starting port is connected I would like to highlight all possible peer ports (possible connection targets). Finally when the connection is created or when the connection process is canceled then I would like to remove the highlighting at all.
I have added 4 new methods to ICreateConnection: void startConnecting(); void endConnecting(); void attachedToSource(ICreateConnectionContext context); void canceledAttaching(ICreateConnectionContext context); The create method can be used for the doneConnecting or attachedToTarget event. commit 035b7318b60f920542b2bd19ab5f27e0a1f4a6e4 Author: mgorning <matthias.gorning@sap.com> 2011-10-12 16:20:26 Committer: mgorning <matthias.gorning@sap.com> 2011-10-13 10:15:35 Parent: 5c6c4821fba0e92a88662da6a22c18c5042cce52 (Chess: removed images) Child: 0a3905c7b17ed6e5398858bb78d2a056efa6a154 (cleanup) Branches: origin/master, master
Great, thanks!
An example implementation is available in the chess example available in the Graphiti Git repository (folder examples, plugin org.eclipse.graphiti.examples.chess). While creating a move connection the possible target squares are highlighted.
Probably I'm lacking perspective here, but: is it assumed/advised that in such a "runtime" scenario, to show some visual feedback when creating a connection, the modification (eg color change) ocurrs inside the pictogram hierarchy, involving a EMF transaction, etc? It doesn't look natural to me (see my related posts in the forum http://www.eclipse.org/forums/index.php/t/240885/ ), nor conceptually very correct (I would not say that such a highlighting belongs to "the diagram"; never would want/expect this to be persisted, for example).
(In reply to comment #7) > Probably I'm lacking perspective here, but: is it assumed/advised that in such > a "runtime" scenario, to show some visual feedback when creating a connection, > the modification (eg color change) ocurrs inside the pictogram hierarchy, > involving a EMF transaction, etc? It doesn't look natural to me (see my related > posts in the forum http://www.eclipse.org/forums/index.php/t/240885/ ), nor > conceptually very correct (I would not say that such a highlighting belongs to > "the diagram"; never would want/expect this to be persisted, for example). No, you're not lacking perspective here. You are right in that this highlighting should not be part of the diagram to persist. I see two possible approaches here: 1) use the Graphiti pictograms model to easily do highlighting and be sure to correctly revert the highlighting to ensure nothing of it gets persisted; that's the approach done in the example. 2) Use something else to do the highlighting, e.g. decorators; in this case border decorators would perfectly fit, they are in the loop but not yet available; maybe it would be worth switching after they are available. In the end this is simply an example that shows how to hook into the connection creation process. What tool builders do in this hook is all up to them. I will add a note on this in the example coding and/or the JavaDoc.
I'm missing here some oportunity to highlight candidate anchors for a connection source, before the connection is actually started (at hovering). This is very related to the feedback that Graphiti already gives (by changing the mouse pointer ) with canStartConnection(), but it cannot be implemented with that, it does not give the chance to turn-off the feedback. At GEF level, this behaviour is possible by the methods public void eraseSourceFeedback(Request request) public void eraseTargetFeedback(Request request) public void showSourceFeedback(Request request) public void showTargetFeedback(Request request) which AnchorEditPart does not override. It would be nice if this methods could alter the VisualState of the Anchors and that this could trigger some display change in the figure.
(In reply to comment #9) > I'm missing here some oportunity to highlight candidate anchors for a > connection source, before the connection is actually started (at hovering). True, that's missing here and it would be nice to have it at this spot. But this is already possible by overriding a hook in the tool behaviour provider (getSelectionInfoForConnection); there you can also influence the way the selection shape is displayed on hovering.
(In reply to comment #10) > > True, that's missing here and it would be nice to have it at this spot. But > this is already possible by overriding a hook in the tool behaviour provider > (getSelectionInfoForConnection); there you can also influence the way the > selection shape is displayed on hovering. I don't think that happens on hovering but on selecting an already existing connection (including the auto-selection of a justly created connection).
Actually we are very near. The only problem is that the ToolBehaviourProvider has a getSelectionInfoForConnection() getSelectionInfoForShape() We could add a getSelectionInfoForAnchor() and modify trivially GFAbstractShape.adaptBackgroundToHover to accept Shape and Anchor. In summary, I propose: - Add to ItoolProvider the method ISelectionInfo getSelectionInfoForAnchor(Anchor anchor); and provide some default implementation (perhaps the name is not ver appropiate, because anchors are not selected? - would this be used only for hovering?) - Change in GFAbstractShape: ==================================== if (!(pe instanceof org.eclipse.graphiti.mm.pictograms.Shape)) return false; org.eclipse.graphiti.mm.pictograms.Shape s = (org.eclipse.graphiti.mm.pictograms.Shape) pe; ISelectionInfo selectionInfo = tbp.getSelectionInfoForShape(s); ==================================== by ==================================== ISelectionInfo selectionInfo = null; if (pe instanceof org.eclipse.graphiti.mm.pictograms.Shape) selectionInfo = tbp.getSelectionInfoForShape((org.eclipse.graphiti.mm.pictograms.Shape) pe); else if (pe instanceof org.eclipse.graphiti.mm.pictograms.Anchor) selectionInfo = tbp.getSelectionInfoForAnchor((org.eclipse.graphiti.mm.pictograms.Anchor) pe); else return false; ==================================== - Add to AnchorEditPart : @Override public void eraseSourceFeedback(Request request) { super.eraseSourceFeedback(request); delegate.getVisualState().setHoverFeedback(IVisualState.HOVER_OFF); } @Override public void eraseTargetFeedback(Request request) { super.eraseTargetFeedback(request); delegate.getVisualState().setHoverFeedback(IVisualState.HOVER_OFF); } @Override public void showSourceFeedback(Request request) { super.showSourceFeedback(request); delegate.getVisualState().setHoverFeedback(IVisualState.HOVER_ON); } @Override public void showTargetFeedback(Request request) { super.showTargetFeedback(request); delegate.getVisualState().setHoverFeedback(IVisualState.HOVER_ON); } - Check that this is consistent with the different types of Anchors and its possible GA (I'm not clear on that, it works for me for a FixPointAnchor that has a Rectangle as GA) ... and Document / add to example :-)
(In reply to comment #12) > Actually we are very near. The only problem is that the ToolBehaviourProvider > has a getSelectionInfoForConnection() getSelectionInfoForShape() > We could add a getSelectionInfoForAnchor() Yes, true. That possibility is missing for anchors. Although this is somewhat related to the completeness of the functionality for this request, I would like to split that off. I have created https://bugs.eclipse.org/bugs/show_bug.cgi?id=363186 to add this enhancement. It seems you have a working implementation for this? If yes, could you attach that as a patch to https://bugs.eclipse.org/bugs/show_bug.cgi?id=363186? That will make keeping the IP log clean much easier. We will have a look into this afer M3.
Bookkeeping: Set target release
Part of Graphiti 0.9.0 (Eclipse Juno)
