So, I would love to drop our manipulator in Rhino 5 and beyond, and just use the gumball. But I don’t think our customers would be happy about it at all unless we could get the same functionality with the rhino 5 gumball (or close enough).
There are 2 things that I think would be necessary. The first is soft manipulation, and the second is extrusion in the manipulator. For soft manipulation we might be able to hack something into the grips themselves (this would lose some functionality, but not too much). But for extrusion in the manipulator, we’d need to integrate with the gumball itself.
So, here’s a proposal of how it could work (and not break rhino 4 compatibility, or plugins that were compiled before the changes).
Make a subclass of CRhinoObjectGrips called CRhinoObjectGripsEx or CRhinoObjectGrips2 or however you want to version the class. I’ll call it CRhinoObjectGrips2 for this example. CRhinoObjectGrips2 has a new member function called ExtrudeGrips which is similar to the DeleteGrips function. It takes an array of indexes of grips to extrude. This extrusion happens immediately, but is only internal state to the grips object, and only takes final effect when NewObject is called. But that way you can get the nice dragging previews while extruding.
You might also add a CRhinoObjectGrips2::ClearGripExtrusions or something if you wanted to.
I’ll change my code to subclass CRhinoObjectGrips2 on Rhino 5, just requiring whatever version it is added in.
Then inside of the autogumball code, where it would usually extrude grips, it runs a CRhinoObjectGrips2::Cast on the grips, and if that succeeds then it calls the ExtrudeGrips function. If not, then it tries to do its own thing as before.
That way if someone subclassed CRhinoObjectGrips, their stuff still works. But if they subclass the new version then they get the new functionality. This is a bit messy, in that you’re basically versioning your parent classes. However, when you break backwards compatibility in Rhino 6, you just collapse all of the CRhinoObjectGrips classes down into the base class… move the new functions into CRhinoObjectGrips and delete the other classes. Plugin developers then just need to search and replace CRhinoObjectGrips2 with CRhinoObjectGrips, and they’re good to go (or if they never used the new functionality, they’re source compatible).
I think that kind of approach could fix a lot of the difficult circumstances that arise from maintaining binary backwards compatibility with Rhino 4.
TL;DR: Please fix all my problems