Ok, but the callback reacts on that when the widget is changed from outside.
Now you want a callback from the widget itself and that is a completely different action.
Data changes, a callback is fired. when developing, it doesn’t matter what triggers the data change. Yes, I suppose one method is to use the UX interaction as the event trigger - but that wouldn’t be a great call back because it wouldn’t fire if anything (say a script) changed the data. For example, in GP there are lots of Midi callbacks that are only based on data changes not on UX events.
I’m also pretty certain that the current WidgetValueChanged callback is not based on UX because the callback is fired if I change the widget via attaching that widget to a plugin param and changing the value via the plugin rather than the UX.
What about the idea using a 2nd widget?
This callback is fired because the widget is somehow manipulated.
Your callback you want is when the widget itself manipulates others.