to be moved (see above)

to be moved (see above)

To be merged in getInterpolatedData for one part, and moved for the other part (see above comment)

Can't see any parsing done over here, is that expected?

getSpline and getPoints don't belong in this class. This class responsibility is to give you the QVariant that corresponds to the keyframe you're asking for, and that's it. Further processing should be deferred to a different class/helper function (may be worth it to create a roto folder with that and the bpoint definition)

This function shouldn't exist, at least in the public interface.
I think there are two different interpolations we need:

• The one that should be in this class, and that should return the QVariant we need to store as a keyframe when we create a keyframe at a new position
• The one that compute the actual points we should be displaying on screen or whatever. That doesn't belong here (see above remark)

(Note that for doubles params, both interpolations yield the same result, that's why there's only one function for them)

This function is super confusing. The whole idea of the KeyFrameModelList is that it should take care of adding/updating/removing keyframes to all the model it manages, and this function is breaking that assumption (possibly breaking some other things depending on usage).

I assume the intent behind that is that Rotoscoping keyframes are somewhat "independent" to whatever other parameters that could be there. Is that why you take extra care to add this keyframe only to that given underlying KeyFrameModel? If it's the case, and we do indeed think independent rotoscoping keyframes are desirable, then we should create a dedicated KeyFrameModelList (which would manage solely roto-related keyframes), and in that case that function is not needed (the normal addKeyframe will do)

To be deleted (see comment below)

To be deleted

Not a big fan of the capture of the monitor pointer here. Could you query it again inside the lambda (it makes sure you have a valid pointer and not a dangling one, for whatever reason).

(Carrying on the interface discussion, if no keyframe at given point, add a global one (without value). Then update regardless.

Seems unsafe to hook on seekToPos here. I think that logic should be in the more general slotRefreshParams ?