Adding Evidence Badge causes Component to shift position

[benloh]

This is a bug in the Evidence Badge Manager: dev-bl/badge-mgr

An Evidence Badge is displayed on a Component to indicate that there is an Evidence Link that has been created between a Resource Item in the Resource Library and that Component. e.g. A student might add a link between the Resource Item "(1) Food Rot Simulation" and the component "Ammonia". A "(1)" badge is then displayed on the Ammonia Component.

The system will automatically add Evidence Badges for Evidence Links that are created programmatically. This works fine. (See the "Food (1)" Component in the Figure 1. below.)

A student can create a new Evidence Link from the Resource Item view. When they create a new Evidence Link, they are asked to connect the Evidence Link item to a Component. See Figure 2, below. Here we are creating a link to the "Ammonia" component. Note the Ammonia component is at y = 80.

After the link is created, an Evidence Badge is added and drawn on the component. When it is drawn, it seems the layout manager recalculates the position of the component and shifts the "Ammonia" Component down. See Figure 3. The Ammonia component y is now at 100.

The badge however does properly stay with the component at the wrong offset. See Figure 4. The Ammonia compoennt is dragged to the lower right and the badge stays.

To replicate this:

1. Check out dev-bl/badge-mgr
2. Start the app
3. Click on a Resource Library Item.
4. Click on "Create Evidence"
5. Click on the red "Link" button in the new evidence (The Resource Item view will close).
6. Note the original position of the Component you want to link to (e.g. Ammonia).
7. Click on the Component (e.g. Ammonia)
8. (Another bug: you have to click somewhere on the graph to force the graph to update and draw the badge, so click on the graph)
9. Note the position of the component has shifted and the badge is drawn.
10. Drag the component around and the badge will dutifully follow.

---

The formula for calculating the position of the badge works well during the initial data load. It is only when a new badge is created that the calculation is off. My guess is it has something to do with updating the bounds of the vprop, but I haven't been able to chase it down yet.

[benloh]

In GitLab by @daveseah on Jun 18, 2019, 09:46

summary: Interactively adding a badge to a component causes its position to shift. The badge itself is drawn in the right position if the component hadn't shifted.

guess: The way that SVG groups and transforms interact is probably the cause.

steps to research:

• outline the layout code and order of operations
• identify groups and transforms being applied
• double-check how transforms and parented groups actually work in SVG

[benloh]

In GitLab by @daveseah on Jun 18, 2019, 13:58

Some things noticed:

• vbadges are created in vprops by attaching to gRoot as does DATA and CHILDREN areas, however they are not STORED in the vprop.
• vbadge instances are stored in PMCData View Model structure by evidenceId.
• vbadge instances are drawn at the time of creation in vprop by adding a group to vprop.gRoot, which can then be removed by called vbadge.Release().
• Every time a vbadge is added to a VProp, it's added as new SVG elements to the vbadge group. The position is determined by the current badgeCount.
• Eventually evidence links can be applied to mechanisms as well, so we should move the badge functionality to the evidence manager

[benloh]

In GitLab by @daveseah on Jul 8, 2019, 13:26

Followup:

This bug still exists; it's probably due to the way one has to implement local/world coordinates in SVG. The model is somewhat different than what we've done before with other graphics systems. This is compounded by the way that vbadges are hacked onto VProp instead of being its own managed vobject-agnostic module.

• Creating an SVG group doesn't automatically create a new coordinate system that you can set with its x,y attributes, though you might THINK this is the way it works. These attributes don't even work on groups, though SVGJS lets you set them and doesn't warn you that it does NOTHING.
• The group instead inherits the coordinate system from its parent, which is usually the <parent> with its origin at 0,0 in the upper left and +x,+y.
• To set a new coordinate system, instead use the transform attribute of the group (e.g. <g transform="translateX(10)">). When you assign this attribute to a group, it doesn't actually move the group itself but it is INHERITED by all contained members. You can then use local coordinates for your contained shape, relative to the shifted origin.

The current codebase assumed a different model where the group elements actually re-establish a coordinate context and drew using local coordinates within each group.

[benloh]

In GitLab by @daveseah on Jul 8, 2019, 13:28

There are issues with using local coordinates in a group using transform to set the origin: most SVG drag and drop libraries appear to use screen coordinates. SVGJS is just a bit too primitive in this regard; PaperJS might have been the better option to use because it appears to have a more mature computer graphics model.

In any case, sticking with SVGJS is in our immediate future, so I'll refactor the drawing code with these new insights in mind as I need to.

[benloh]

In GitLab by @daveseah on Oct 27, 2019, 09:42

I believe this was fixed quite some time ago with Ben's new vbadge system.

[benloh]

In GitLab by @daveseah on Oct 27, 2019, 09:42

closed