[FEAT] render parallel gateway #222
Conversation
tbouffard
changed the title
aibcmars
added
the
WIP 🚧
| } | ||
|
|
||
| protected paintInnerShape(c: mxgraph.mxXmlCanvas2D, x: number, y: number, w: number, h: number): void { | ||
| super.paintInnerShape(c, x, y, w, h); |
There was a problem hiding this comment.
❓ I see this super call in the 2 subclasses, could we remove it with the following
- in the super class, move the code to the enclosing
paintVertexShapemethod right before thepaintInnerShapecall - then we can remove the super calls
- the
paintInnerShapecan then be made abstract
| c.setFillColor(this.stroke); | ||
| c.setStrokeWidth(0); | ||
| } | ||
| protected getScaledGeometry(x: number, y: number, w: number, h: number): { xS: number; yS: number; wS: number; hS: number } { |
There was a problem hiding this comment.
❓ good to share code! 😄
I have noticed that we didn't communicate well about the icon scaling and position of elements in the task (what I did) and gateway (what you did) shapes and we now have 2 ways of doing things 😯
I have introduced a MxScaleFactorCanvas class in charge of hidding the scaling
// vanilla canvas calls when a scale factor must be applied to positions
const scaleFactor = 0.26;
c.moveTo(8 * scaleFactor, 39 * scaleFactor);
c.lineTo(12 * scaleFactor, 25 * scaleFactor);
// MxScaleFactorCanvas
const canvas = new MxScaleFactorCanvas(c, 0.26);
canvas.moveTo(8, 39);
canvas.lineTo(12, 25);This makes the code clearer than in the current gateway implementation. However, it only scales the x and y direction with the same value.
In the gateway side, you introduce a way to manage the translation required to position the icon. In the task shape, this is done globally by a translation of the current cursor which has a side effect: after icon drawing, the orgin coordinates have changed, so subsequent drawing won't be done at the right place, except if we remember to reset the origin coordinates at the end of the task icon drawing! For sure, this will create issue in the future when we will draw the task markers.
So to me, we have to merge the good part of the 2 implementations in a new single one, especially if we want to benefits of it for event icons.
I suggest that we keep the gateway icon implementation as it is now in this PR but we manage a refactoring very soon (let's say next week) with @csouchet as well. If you agree, I can create an issue to track this.
There was a problem hiding this comment.
yes, done in 226 so resolving this conversation
| this.putCellStyle(ShapeBpmnElementKind.GATEWAY_PARALLEL, style); | ||
| } | ||
|
|
||
| private configureGatewaysStyle(): void { |
There was a problem hiding this comment.
@aibcmars Can you remove unnecessary line style[this.mxConstants.STYLE_PERIMETER] = this.mxPerimeter.RhombusPerimeter; ?
There was a problem hiding this comment.
can we please stop noticing this? we have to understand why this is put in all mxGraph examples
This seems to be ok without for our rendering but we do not know what is the purpose of this.
I suggest we manage this later and track this with a dedicated issue
What I have understood so far is that the perimeter provides the list of points that can be used to attach edges to the current shape. This could be usefull for automatic rendering.
I know we are supposed to have the waypoints in the BPMN files that should define the point on the shape where the edge must be attached, but without exactly knowing what is going on, it is to early to remove the perimeters from the style IMHO
There was a problem hiding this comment.
I agree with Thomas, as yesterday stated: we have found it occurs in all mxgraph examples concerning RHOMBUS.
aibcmars
removed
the
WIP 🚧
tbouffard
added
enhancement
|
The gateway render is now ok with commit 0701745
|
Closes #198