I have tried a lot of tutorials on the website on how to programming the slicer extension using c++. I could built a very simple extension and load it successfully. However, what I found difficult is how to get the information and send the result from and to the slicer. Different information might have different names, nodes or data structures, how could I get this information? There seems no documents on it. Such as get the images of one CT scanned images, get the models of the 3D reconstructed models by programming and so on. Which data format is the slicer using? I thought there should be some manuals or tutorials on it.
It sounds like you are making progress. It’s true that there many things you could do with Slicer that don’t have manuals or tutorials. Slicer is free and supported by people who use it as part of their research work. So while we are happy to help answer specific questions, a lot of the work for developers involves reading code and examples to learn how the pieces fit together.
Fortunately everything is open and transparent, so it’s possible to study everything and see how it works using standard computing tools like debuggers and IDEs.
Thank you very much! Yes you are right, thank goodness that everything is open and transparent. Now I am trying to read the code and examples one by one.
I have one problem now. I noticed that there are three classes for a typical loadable module. Such as Module, Module Widget, and Module Logic. The Module Widget holds for the GUI. The slot function in this module should call the method from the Module Logic. However, how to obtain the handler/pointer of the Module Logic. I saw no variables in Module holding this pointer and createLogic() function would lead to memory leak. How to obtain the Module Logic pointer from Module Widget using c++ ?
The logic classes can be thought of like a utility library for the module, where algorithms and other non-user interface code can be kept. By default a module’s gui code will create one instance of the logic in the createLogic method and re-use it (storing a pointer in the widget instance), but since they are typically very lightweight you’ll also see them created on the fly when needed.
I’m sure it looks messy, but it’s worth looking at the inheritance structure carefully to see how common functionality is factored out through the levels of the inheritance hierarchies. There are distinct trees for widgets, data, logic, visualization, etc.
One other suggestion: we typically find that if people start with python scripted modules they learn some of the basics and then it’s easier get into the C++ code.
Thank you very much. I firstly figure out the mechanism of Q_Q and Q_D. And found it useless with this problem and then go though all the base classes and found out the logic pointer could be obtained with appLogic() in Module and logic() in ModuleWidget.
Although current problem has been solved, it seems a long long way to go with slicer…