Is it necessary to add toolSelectedCallback feature?

[xingbofeng]

Prerequisites

• [x] Are you running the latest version?
• [x] Are you reporting to the correct repository?
• [x] Did you perform a cursory search?

For more information, see the CONTRIBUTING guide.

Description

There is the method that pointNearTool and toolSelectedCallback that I can only select the tool by mousedown near the handle, but I want to select the tool by mousedown inner the measurement by the pointInnerTool setted by myself. So I changed the mouseDown.js:

  const annotationToolsWithPointInnerClick = activeAndPassiveTools.filter(
    tool => {
      const toolState = getToolState(element, tool.name);
      const isInnerPoint = 
        toolState &&
        toolState.data &&
        tool.pointInnerTool &&
        toolState.data.some(data =>
          tool.pointInnerTool(element, data, coords, 'mouse')
        );
      return isInnerPoint;
    }
  );
  if (annotationToolsWithPointInnerClick.length > 0) {
    const firstToolInnerPoint = annotationToolsWithPointInnerClick[0];
    const toolState = getToolState(element, firstToolInnerPoint.name);
    const firstAnnotationInnerPoint = toolState.data.find(data => 
      firstToolInnerPoint.pointInnerTool(element, data, coords)
    );

    if (firstAnnotationInnerPoint && firstToolInnerPoint.innerSelectedCallback) {
      firstToolInnerPoint.innerSelectedCallback(
        evt,
        firstAnnotationInnerPoint,
        'mouse'
      );
      return;
    }
  }

I Have add my custom feature in my version(forked from the official), @dannyrb If you think it's necessary to add it , I will create PR.

[dannyrb]

It's cool to see other people playing around in the listeners/dispatchers ^_^

Tools that implement pointNearTool are basically saying that, if this is true, I want to handle the incoming event, and I want to do it in the library standard way of dragging all handles (unless I've overridden the default behavior).

Do you see pointInnerTool being used for behavior other than dragging all annotation handles? Do you have any practical real world examples of different behavior we might want to use when this is true? Is this behavior that should be a default implementation for innerSelectedCallback on BaseAnnotationTool?

To me, the biggest questions/risks are:

• pointInnerTool has a higher chance of multiple tools reporting back true
  • Improved concepts of annotations depth/layers so we can determine which tool should handle events
  • Pushing annotations up/down layers may require a new annotation::selected state
• Should there be a default behavior? Or some canned strategies that can be set with flags?

CC: @JamesAPetts

Thanks for the suggestion, @xingbofeng! It's really encouraging to get feedback and feature requests for this part of the library.

[xingbofeng]

Thanks for your replay, and thanks for cornerstoneTools project. I changed it for the reason that doctor using our pulmonary nodule medical image product think drag the nodule (we use EllipticalRoiTool and FreehandMouseTool based on cornerstone and cornerstoneTools) is too hard, so I changed the code of EllipticalRoiTool and FreehandMouse, add pointInnerTool and changed mouseDown.js.

In the opinion of my partner doctors who is in China, because the nodule is too small, dragging the nodule by mousedown at the side of roi is too hard for them.

As you say, pointInnerTool has a higher chance of multiple tools reporting back true, i have some idea now:

• Darg or active the measurement by mousedown the side of measurement or inner measurement depends on what kinds of annotation tool. for example AngleTool, i think it is the side of measurement but not inner measurement.
• Give configuration, for example selectedBehavior, we change the selected Behavior, nearTool or innerTool.

Can you give me some advice? Looking forward to your reply.

[JamesAPetts]

Just to play devil's advocate, how would you intend to deal with the case of drawing one region inside the other in this pointInnerTool mode?

e.g.:

As the passive functionality of the first ROI would grab the event and you would instead start moving the ROI.

[dannyrb]

In the opinion of my partner doctors who is in China, because the nodule is too small, dragging the nodule by mousedown at the side of roi is too hard for them.

For this specific use case, I would recommend pointNearTool having a larger threshold/distance for when it would return true to make the nodules easier to grab/drag. You could even change pointNearTool to conditionally use pointInnerTool logic when the width or height of the shape is small.

If any of the above things are not easy/obvious to do in the current setup, then maybe we could explore ways to make modifications like that more accessible to developers?

pointInnerTool, to me, feels more like a way to initiate a behavior that is different than pointNearTool's. If you had said:

• When I click near the annotation, I want it to be draggable
• When I click inside the annotation, I want it to grow by X%

Then I would be more keen to add it as the tool logic changes based on the context/interaction.

@JamesAPetts, your point is a good one. We'd need to be very careful about how/where we implement this as a default as passive tool interaction currently takes priority over active.

[xingbofeng]

Just to play devil's advocate, how would you intend to deal with the case of drawing one region inside the other in this pointInnerTool mode?

e.g.:

As the passive functionality of the first ROI would grab the event and you would instead start moving the ROI.

@JamesAPetts I'm not consider this problem,now i just choose the first annotation of the array.I need to consider it.

Thanks for the suggestion of @dannyrb ,i will talk about this suggestion with our doctors, now i think it's not necessary to add this feature, maybe.Thanks!