Component is the new controller

[bakpaul]

While working on prefabs we have a new type of python object that is to be stored in the graph, so it needs to inherit from BaseComponent somehow. The dirty way to do this was to inherit from Controller which doesn't make sens as it is not meant to be actively doing something.

At first I only wanted to make a python class named Component until I realized that it was meaningless without an ability to override handleEvent. Looking at that I realized that BaseContoller is nothing more than a BaseObject. So merging both makes sense.

This PR keeps the old Controller implementation, just replaced the name to Component and added both to the python bindings. Therefore, such as in the actual core of SOFA, we have controllers and components which are basically the same but named differently

[bakpaul]

@damienmarchal could you make a review on that PR ?

[epernod]

very important suggestion....

[hugtalbot]

sounds like the name of the next blockbuster movie

"Component is the new controller"

[damienmarchal]

I think the reference to "user interaction" was appropriate for "controller" but not to a BaseComponent binding which have a more wider use case scope.

Some update of the doc are thus needed.

[bakpaul]

Thank you ! I just did it.

[damienmarchal]

@damienmarchal could you make a review on that PR ?
@bakpaul ok

Inherting from BaseComponent (or BaseObject) to extend them in python is a valid move.

You are right that the SofaPython3 API for Controller was actually not following the c++ Controller's API and it is thus more generic... so it fit to inhert from BaseComponent forwarding the event's in a generic way.

Looks ok so.

=> Actually there is also work to do on making the Sofa.Node binding overridable.