fix(AbstractWidget): clear activeState

[floryst]

Context

activeState should not be set after calling deactivateAllHandles.

Results

activeState is cleared after calling deactivateAllHandles.

Changes

• Documentation and TypeScript definitions were updated to match those changes

PR and Code Checklist

• semantic-release commit messages
• Run npm run reformat to have correctly formatted code

Testing

• This change adds or fixes unit tests
• Tested environment:
  • vtk.js:
  • OS:
  • Browser:

[jourdain]

Don't recall the logic but LGTM

[floryst]

The only weird case I can think of is what should happen when you do the following:

widgetManager.grabFocus(widget);
widget.deactivateAllHandles();

Though if you are doing manual activate/deactivate of handles, maybe you don't intend on using grabFocus/loseFocus.

[finetjul]

deactivateAllHandles() being a convenient function and not the only way to deactivate handles, I wonder if a more robust fix wouldn't be :

• for the widget to observe the activeState, and if it becomes inactive,then set activeState to null.
• or when deactivating a substate in the widget state, it could check if it is the same as widget.getActiveState() of the associated widget and if so, set it to null.

[floryst]

I like the watch approach better, since I agree with your comment that it's not the only way to deactivate handles.

One thing we would have to watch out for with this change is how we handle grab/loseFocus. Suppose we do the following:

const polylineWidget = vtkPolyLineWidget.newInstance()
const w = widgetManager.addWidget(polylineWidget)
// this calls widgetState.getMoveHandle().activate()
widgetManager.grabFocus(w)

// sets model.activeState = null
w.deactivateAllHandles()

In this state, the widget manager still thinks the widget is focused, so all events go to the PolyLineWidget. However, since the widget's activeState is now null, no mouse event is processed.

[finetjul]

Can the widget in focus be different than the activeState ?
if not, then deactivating the widget in focus could also make it loose focus.

[floryst]

I certainly think so. An example would be a widget that processes mouse events while in focus but there is no handle state. A concrete example of this would be the PolyLineWidget, but there's no move handle.

The concern is mostly for existing widgets, e.g. a focused PolyLineWidget means you're drawing, but no active state means nothing happens. This is more of a "developer beware" note that I think would be good to document.