Agreed - scripted modules should have all the same features and behave consistently with any other module (as much as possible).

Couldn't agree more. Few years ago, in an attempt to address this, we created:

vtkSlicerScriptedLoadableModuleLogic [1]

Similarly to loadable module, this would allow the logic of scripted module to be instantiated before the associated representation.

This raises the following questions / remarks:

(1) Being able to leverage QtCore classes in python logic has been great.

(2) Currently, loadable logic only depends on VTK/ITK. The base class derives from vtkObject and there are no dependency on Qt. We could either:

• introduce a base class named QtCore/qSlicerModuleLogic (similar to vtkSlicerModuleLogic)
• or allow existing vtkSlicer[Name]ModuleLogic to depends on QtCore

[1] https://github.com/Slicer/Slicer/blob/master/Base/Logic/vtkSlicerScriptedLoadableModuleLogic.h

Yes, it's aways been possible for scripted logics to use qt and being explicit that QtCore is exptected makes sense. This would give a hook for implementing the things Andras mentions.

Making module logic depend on Qt would be a huge change. For me it would only make sense if we made all MRML classes to be based on Qt instead of MRML but then we would depend on Qt forever, for everything. Using Qt instead of VTK would have serious performance consequences, as VTK observers are typically about 10x faster than Qt signals/slots.

Developers can still leverage qt features in their scripted module logic if Qt dependency is not an issue (it's typically not, as scripted modules are mostly high-level application modules anyway).

Something like that is done for the module widget would work well:

• create Python object
• forward C++ interface method calls to Python
• have a slicer.modules.somescriptedmodule.logic().self() method for accessing the complete python logic object

I see that Python object creation code is there but it is commented out:
//-----------------------------------------------------------------------------
vtkMRMLAbstractLogic* qSlicerScriptedLoadableModule::createLogic()
{
// Q_D(qSlicerScriptedLoadableModule);

vtkSlicerScriptedLoadableModuleLogic* logic = vtkSlicerScriptedLoadableModuleLogic::New();

// bool ret = logic->SetPythonSource(d->PythonSource.toStdString());
// if (!ret)
// {
// logic->Delete();
// return 0;
// }

return logic;
}

I see that Python object creation code is there but it is commented out:

Indeed, at that time we didn't have a use case. The idea of having a dedicated Python class to implement the logic wasn't formalised.

Now we have more use case, it would be great to have the scripted logic instantiated by the module manager.

That said, some more work would be needed to implement the "reload" function directly within the module manager. Otherwise, the existing "Reload and Test" wouldn't be as useful.