Community
Participate
Working Groups
The highlighting of a guide line is offset in a compartment. To reproduce: - Create a Logic Diagram. - Create a circuit with a LED inside. - Turn on the ruler. - Create a guide line through the circuit compartment. - Try to snap the LED to the guide line. RESULT: It works fine, but the highlighting of the guide line in red is in the wrong spot. It looks to be offset by the distance between the diagram's origin and the compartment location.
Created attachment 83561 [details] Proposed Patch After some investigation, I think I've concluded that this is a GEF bug. In the case of trying to snap an editpart inside the ShapeCompartmentEditPart to a guide, when the contentPane is retrieved in SnapFeedbackPolicy, the contentPane is the "BorderItemsAwareFreeFormLayer". This layer is really the ShapeCompartmentEditPart itself, so when the contentPane gets translated in the next line: "contentPane.translateToParent(loc)" (where "loc" is the location of the guide" the variable "loc" which is used to show the laser red line, is therefore translated incorrectly. Since we are using the bounds of the ShapeCompartmentEditPart, and not the editpart we're trying to snap, this explains the offset of the laser red line, between diagram's origin and the compartment location. I've attached a patch of what does fix the problem. Instead of directly retrieving the host, we get the hosts viewer, and the contents, which ignores the the fact that the selected edit part is inside ShapeCompartmentEditPart. Trying to fix this on the GMF side would mean changing how the ShapeCompartmentEditPart's contentPane is retrieved, and could lead to some unpredictable results.
for reference, this is a duplicate of Bugzilla 78462. Also, in the situation that this fix ever gets implemented, SnapToGeometryEx for GMF would need to have some changes as well to accommodate for the absolute coordinates. The code is already there, you just have to uncomment it
Is this bug going to be fixed for the next release of GEF ?
