ParaView plugin loading mechanism should be refactored
Loading a plugin in ParaView is a very complex code path. It is also a complex task as many cases needs to be taken into account, however the current state of plugin loading code path is due not to design constraints but to iterative developpements without vision of where the feature would finally arrive after 15 years.
Here is a list of class involved by loading a plugin:
- vtkSMProxy
- vtkPVServerManagerPluginInterface
- vtkSIProxyDefinitionManager
- vtkPVPluginLoader
- vtkPVPlugin
- vtkPVPluginTracker
- pqPluginDialog
- pqPluginManager
- vtkSMPluginLoaderProxy
- vtkSMPluginManager
- vtkPVPluginsInformation
- pqProxyGroupMenuManager
The information about a plugin is moved around a lot, with duplicate information. There are many methods with similar names and unclear usage.
While I do not have a clear design in mind, I think it would be beneficial to refactorize that whole stack.