Hovering doesn't work properly on Petri net places with high token count

[jvoigtlaender]

Note this:

and this:

vs. this:

[nimec01]

The issue here is that the token count is not displayed, right?

Could you provide a concrete task instance where this happens?

[jvoigtlaender]

The problem is that the "7 bullets" inscription does not react to hovering at all, neither actively nor passively. In contrast to how "several bullets" displayed directly (without number printing) react.

Let's take this:

If I move the mouse pointer to the circle border, I get this:

And when I move the mouse pointer to the bullets themselves, again:

Now consider this:

If I move the mouse pointer to the circle border, I get this:

And when I move the mouse pointer to the number or the bullet, I get this:

An example instance where this happens (in the goal net) is this:

Right (ReachInstance 
  { netGoal = (NetGoal 
      { drawUsing = Circo
      , petriNet = (Net 
          { places = (mkSet [ s1, s2, s3, s4 ])
          , transitions = (mkSet [ t1, t2, t3, t4 ])
          , connections = 
            [ ( [ s2, s4 ], t1, [ s1, s2, s4 ] )
            , ( [ s2, s3 ], t2, [ s1, s3 ] )
            , ( [ s2, s4 ], t3, [ s1, s2 ] )
            , ( [ s1, s3 ], t4, [ s4, s3 ] ) 
            ]
          , capacity = Unbounded
          , start = (State 
              { unState = (listToFM 
                  [ ( s1, 1 ), ( s2, 1 ), ( s3, 1 ), ( s4, 0 ) ]) 
              }) 
          })
      , goal = (State 
          { unState = (listToFM [ ( s1, 7 ), ( s2, 1 ), ( s3, 1 ), ( s4, 0 ) ]) 
          }) 
      })
  , minLength = 8
  , noLongerThan = (Just 8)
  , showGoalNet = True
  , showPlaceNames = False
  , maxDisplayedSolutions = 10
  , shortestSolutions = (Right ([ t4, t1, t1, t1, t1, t1, t1, t3 ] :| [ ]))
  , withLengthHint = Nothing
  , withMinLengthHint = True
  , rejectSpaceballsLength = (Just 4) 
  })

[nimec01]

The difference between the two diagrams might seem small, but the difference in the diagram structures are crucial here. The structure for a Petri net with a lower token count (also without label annotations) looks like this:

<svg>
  <g>
    <path class="node" /> <!-- The actual circle -->
    <path class="token" /> <!-- The token symbol -->
    <path class="nlabel" /> <!-- The name of the place -->
  </g>
  <g>
    <path class="rect" /> <!-- The trasition body (the actual rectangle) -->
    <path class="" /> <!-- The transition label -->
  </g>
  <g>
    <path class="edge" /> <!-- The arrow line -->
    <path class="edge" /> <!-- The arrow head -->
  </g>
</svg>

That is quite nice, as the required CSS for highlighting then could work like this: "If a group is hovered then apply the styles for the specific elements inside it".

The structure for a diagram with higher token count however looks like this:

<svg>
  <g>
    <path class="node" /> <!-- The actual circle -->
  </g>
  <g>
    <path class="" /> <!-- The token amount -->
  </g>
  <g>
    <path class="token" /> <!-- The token symbol -->
  </g>
  <g>
    <path class="nlabel" /> <!-- The name of the place -->
  </g>
  <g>
    <path class="rect" /> <!-- The trasition body (the actual rectangle) -->
    <path class="" /> <!-- The transition label -->
  </g>
  <g>
    <path class="edge" /> <!-- The arrow line -->
    <path class="edge" /> <!-- The arrow head -->
  </g>
</svg>

Notice how every element related to a specific node is split into multiple groups. That is problematic since there is no way to tell whether two groups are related with each other or not. If you now try to create CSS rules, you would need to do something like this: "If any element related to a specific node is hovered then apply the specific style for all elements related to this node". But there is no way to do this with CSS (the current implementation basically tries to do this).

The same structural change also appears when enabling label annotations.

---

The immediate thought would be to change the code such that only diagrams with the "easier" structure are generated. But this does not seem to be possible with the "diagrams" library. That's because the library is not intended to be used that way (as an SVG builder; I have tried this already). It basically determines on its own whether two elements should be inside a group or not.

[jvoigtlaender]

So our escape hatch is to make it so that if a Petri net task turns on hovering (always, or with an according config option set to make it so), then other parameters in the config prevent Petri nets with more than five tokens somewhere from appearing in the task description?

What confuses me a bit right now is this bit above:

The same structural change also appears when enabling label annotations.

But didn't you observe that even after enabling label annotations the hovering still works (contrary to my expectation from previous information)?

[nimec01]

What confuses me a bit right now is this bit above:

The same structural change also appears when enabling label annotations.

But didn't you observe that even after enabling label annotations the hovering still works (contrary to my expectation from previous information)?

Turning on label annotations only destroys parts of the highlighting feature. Transitions and edges are not affected at all, only node highlighting breaks. The bug you observed and described in the issue description is the result of that (only difference is that the trigger here is not the label annotating but the higher token count).

I don't think we want that state neither.

---

So our escape hatch is to make it so that if a Petri net task turns on hovering (always, or with an according config option set to make it so), then other parameters in the config prevent Petri nets with more than five tokens somewhere from appearing in the task description?

Restricting instances to only have diagrams with the "sane structure" would be an option. But this would not fix the issue for tasks that also show diagrams during evaluation. Depending on the user input, diagrams there could then still have places with higher token counts.

But this should, of course, only be a temporary solution until we find a better/cleaner solution.

[nimec01]

Another idea that came to my mind would be to post-process the generated SVG. The generated SVG (the elements to be more specific) would still need to have all the necessary context information (for example via data-* attributes) but we would then be able to transform the SVG into a shape that allows us to easily write CSS rules for it.

You could of course also think about trying to do the highlighting directly via JavaScript (without transforming it beforehand), but I don't really like that approach.

[jvoigtlaender]

Let's hold off on attempting a general solution, also since there might have to be further adaptations for drawNetWithCapacity in https://github.com/fmidue/modelling-tasks/pull/558/changes#diff-49e0fa3bfff35fc4e564597328a4d032c7d187b28a1fc3479e0b83414f9cd8cb.

Concerning the escape hatch, this is true:

But this would not fix the issue for tasks that also show diagrams during evaluation. Depending on the user input, diagrams there could then still have places with higher token counts.

but maybe not all too problematic. The "discoverability feature" of the highlighting is mostly needed by students when they are looking at the task and trying to solve it.

For now, continue there: #572 (comment)