Moving points does not emit data change event

[jwindhager]

🐛 Bug

Moving points in the viewer does not emit Points.events.data event

To Reproduce

Steps to reproduce the behavior:

1. Add a points layer
2. Register a callback for Points.events.data
3. In the viewer, select and drag points and observe how the event is not emitted

Expected behavior

To my understanding, Points.events.data should be emitted whenever the data changes, so either

• while the points are being moved (mouse drag), or
• after the points have been moved (mouse release)

Additional context

A workaround is possible by additionally listening to mouse drag events. However, it this case, it is unclear how to differentiate between point selection and point move, see #2259.

[sofroniewn]

Thanks for filing @jwindhager - I know @jni has flagged this too. It is because we modify the data in place so the setter isn't called on the data property. We could just manually call the event here though

napari/napari/layers/points/points.py

Lines 1725 to 1727 in edee9af

	self.data[np.ix_(index, disp)] = (
	self.data[np.ix_(index, disp)] + shift
	)

which would be an easy one line fix as we work on a more elegant solution

[jwindhager]

Thanks! Happy to submit a pull request for this. Just want to make sure that this doesn't break things? For example, if some existing plugins do some heavy lifting in the Points.events.data event handler (e.g. I/O), it might be a suboptimal idea to now change the behavior to emit this event during a mouse drag operation... Maybe there should be two separate events, e.g. data_updating and data_updated or something of that sort?

[sofroniewn]

That's a reasonable concern, we could do something a little more complex like use a recently added ability to block and count event emission, see #2197. We would add event emission to the points move function after the line I indicated above, but then inside the mouse function we could block event emission when the mouse gets pressed, then when the mouse gets release we could count the number of emitted events, and if greater than 0 we could emit one manually there. Thoughts? cc @jni

[jni]

Indeed, affinder specifically writes data each time the affine matrix changes, so this would re-save the affine matrix at each increment. It's tiny but I think that would add up. I like @sofroniewn's proposed solution.