@pieper mentioned here that it would be a good idea to remove the circular dependencies.
The simplest approach for me seemed to be just to move common functionality into qt-scripted-modules/RegistrationLib/Visualization.py.
Now CompareVolumes simply does import RegistrationLiband LandmarkRegistration.py and Visualization.py don’t import CompareVolumes any more.
You can take a look at the changes here:
Thanks @koeglfryderyk - I haven’t worked with the code in a while, so maybe what you are proposing is the most expeditious way to remove the circular dependency. My thought though had been that the CompareVolumes code is more of the helper library and that LandmarkRegistration is the specific application so to me, putting the visualization and widgets in CompareVolumes would feel more natural. I don’t know if you had looked into that and prefer this organization?
My thinking was: CompareVolumes.py and LandmarkRegistration.py are scripted modules, so any code that they share (or that could be reused) should be moved to a helper library, e.g., to RegistrationLib/Visualization.py
This way, any scripted module that wants to use this code can just import RegistrationLib
Does that make sense?
If you think it’s a lot of work to change we can leave it in RegistrationLib, but to me the visualization features and the corresponding widgets are proper to CompareVolumes. The other RegistrationLib code is to support the different kinds of transforms that plug into LandmarkRegistration. Since CompareVolumes is the more general module it makes more sense to me that other modules would only want to import the lower level code. But your point is true that since they are both available in the app it doesn’t make any real practical difference.