Community
Participate
Working Groups
Build Identifier: I20100608-0911 When adding a new element on the diagram with snap to grid enabled, the new element is not actually added "snapped to grid". Instead you must add, then move the element. Reproducible: Always Steps to Reproduce: To reproduce: 1) show the grid (right click the diagram: View / Gird) 2) select the diagram, go to the properties view, "Rulers and Grid" tab, adjust the Grid spacing to be 0.5 so that it is easy to view 1) add two Geo-shape rectangles (place the mouse pointer way from a grid point when adding the shape) 2) add a line between them (try with rectilinear and oblique routing) - at this point you can see that the borders of the shape are not aligned with the gird. Rather it is added exactly where the mouse was. Expected behavior is that two sides of the note should be aligned with the grid. I would expect the left and top. Alternatively the entire shape size should form to the grid spacing so that all sides are on grid upon adding the element. - looking at the line, we can see that its source and target are also not snapped to a grid point. Expected behavior: source/target and any intermediate bendpoints should be snapped to grid points. After we have arranged the shapes and connections on the diagram to be 'on grid', if we move one of the shapes, the connectors are no longer guaranteed to stay 'on grid' which means that the we must again adjust the position of the connector manually to "snap to grid".
I can confirm this issue. It is especially annoying when working with large diagrams with lots of elements.
Created attachment 253399 [details] Does not fixes the subj per se, but allows subclasses to fix The attached patch allows subclasses to implement custom snap-to-grid behavior for implicit bendpoints created by moving of the existing bendpoints or segments of the links with recti-linear routing. Similar "make protected" trick had already been done in the past for logically similar showMoveLineSegFeedback. Without these methods as protected, subclass should not only copy-paste the whole org.eclipse.gmf.runtime.gef.ui.internal.editpolicies.ConnectionBendpointEditPolicy but also its subclass org.eclipse.gmf.runtime.diagram.ui.editpolicies.ConnectionBendpointEditPolicy. See e.g a fix for Papyrus (copy-pasting both classes) at: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/gmfdiag/org.eclipse.papyrus.infra.gmfdiag.common/src/org/eclipse/papyrus/infra/gmfdiag/common/linklf/editpolicies/notformars?h=bugs/442157-luna-1.0.2-linksLF
Created attachment 253400 [details] BaseSlidableAnchor: some methods made protected to allow subclasses to snap anchors to grid Attached patch makes protected a few methods in the BaseSlidableAnchor class. This would significantly simplify (and avoid copy-paste) an implementation of the slidable anchors that are snapped to grid at the linking time. This patch is of lower importance than the one for get.ui above because resulting copy paste is not as ugly as for the ConnectionBendpointEditPolicy. So I have separated it from the first one.
Created attachment 253402 [details] Helper methods in the RectilinearRouter made protected to reuse in custom rectilinear router which fixes the subj For Papyrus we have implemented the custom rectilinear router which: - respects Snap to grid for the implicit bendpoints introduced when switching from oblique to recti- routing - enforces that the last / first segment is always orthogonal to the node side, avoiding the visual anchor position different to the user-set anchor position. The latter happens with default RectilinearRouter when first or last segment is parallel to (and in fact hidden by) the node side - routes the segments from/to affixed items orthogonal to the side of the parent node to which affixed node is attached The proposed code for Papyrus Luna is available at http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/gmfdiag/org.eclipse.papyrus.infra.gmfdiag.common/src/org/eclipse/papyrus/infra/gmfdiag/common/linklf/router/SnapToGridRectilinearRouter.java?h=bugs/442157-luna-1.0.2-linksLF Without any surprize this code extensively uses the helper methods originally implemented in RectilinearRouter. Proposed Papyrus code just copy-pastes all the helper methods in the separate RectlinearRouter2 class which is ugly: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/gmfdiag/org.eclipse.papyrus.infra.gmfdiag.common/src/org/eclipse/papyrus/infra/gmfdiag/common/linklf/router/RectilinearRouter2.java?h=bugs/442157-luna-1.0.2-linksLF Instead It would be much better to just make them protected in the super-class in the GMF Runtime, thus the proposed patch. This patch is less important for Papyrus than the one for ConnectionBendpointEditPolicy but more important than the one for BaseSlidableAnchor
I would kindly ask you to submit the patches above for Mars. It would allow to test the proposed implementation with Papyrus diagrams users and hopefully may create a basis for backporting of the fix into GMF Runtime in Mars+1.
New Gerrit change created: https://git.eclipse.org/r/47747
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/47747 That gerrit (for GMF Tooling) is unrelated, just mentioned this bug in commit comment. Removed from "See also"
Gerrit change https://git.eclipse.org/r/47747 was merged to [master]. Commit: http://git.eclipse.org/c/gmf-tooling/org.eclipse.gmf-tooling.git/commit/?id=8abf9530dedad99676b54c0304b72eb62af59433
