_Context: Slicer built against `VTK 9.0.20200825`_
### How are the custom VTK classes wrapped ?
We wrap our custom VTK classes using [vtkMacroKitPythonWrap.cmake](https://github.com/jcfr/Slicer/blob/4696-support-build-with-vtk89/CMake/vtkMacroKitPythonWrap.cmake) as well as modified version of [vtkWrapPython.cmake](https://github.com/jcfr/Slicer/blob/4696-support-build-with-vtk89/CMake/vtkWrapPython.cmake) and [vtkWrapHierarchy.cmake](https://github.com/jcfr/Slicer/blob/4696-support-build-with-vtk89/CMake/vtkWrapHierarchy.cmake) adapted from prior version of VTK.
_Context: Slicer built against `VTK 9.0.20200825`_
### How are PythonQt and VTK integrated ?
Few years ago, we worked with the maintainer of PythonQt to add the concept of `PythonQtForeignWrapperFactory. To ensure VTK object associated with Qt signals, slots and properties are properly wrapped/unwrapped, we then implemented [ctkVTKPythonQtWrapperFactory](https://github.com/commontk/CTK/blob/support-build-with-vtk89/Libs/Visualization/VTK/Core/ctkVTKPythonQtWrapperFactory.cpp) distributed in `CTK`.
_Context: Slicer built against `VTK 9.0.20200825`_
cc: @dgobbi @lassoan @pieper
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [August 29, 2020, 5:03pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/2 "2020-08-29T17:03:28Z")
Given that GetObjectFromPointer() relies on GetClassName(), what does this return?
```
slicer.app.mrmlScene().GetClassName()
```
If that returns the correct class name, then yes, the ClassMap is the most likely culprit. The worst possibility is that there are multiple instances of the ClassMap in Slicer. The singleton that contains the ClassMap is created in the vtkWrappingPythonCore library:
```
// constructs the singleton
void vtkPythonUtilCreateIfNeeded()
{
if (vtkPythonMap == nullptr)
{
vtkPythonMap = new vtkPythonUtil();
Py_AtExit(vtkPythonUtilDelete);
}
}
```
The dynamic library handling for the wrappers changed in VTK 9 as compared to VTK 8. There used to be “vtkCommonCorePythonD” library in addition to the “vtkCommonCorePython” module.
The old “PythonD” libraries relied on the system loader to ensure that dependent libraries were loaded, e.g. to ensure that vtkCommonCorePythonD would be loaded if vtkCommonMiscPythonD was loaded. This is important because these “D” libraries contained the actual Python extension classes for VTK. So if you imported vtkCommonMisc, then the wrappers would automatically know about all the classes in vtkCommonCore even if you didn’t import vtkCommonCore.
In VTK 9, the dependency handling has changed. In VTK 9, when you import vtkCommonMisc, the initCommonMisc() method will import vtkmodules.vtkCommonCore and all other dependencies. So dependencies are handled through pythonic means, rather than being handled by the system loader.
I’m not saying that this change to the module loading is necessarily related to your custom class issue, but it is something to keep in mind while you are debugging. Take a look in the InitImpl.cxx code for your custom Python modules to make sure that dependencies are properly loaded.
It should go without saying that if you call `slicer.app.mrmlScene()` without first importing your `mrml` wrappers into Python, then a vtkObject is all you should expect to get.
* * *
Another possibility, though unlikely, is that multiple inheritance is gumming things up. Do your custom-wrapped objects use multiple inheritance?
---
### Author:  [@jcfr](https://discourse.vtk.org/u/jcfr)
#### Post date: [August 29, 2020, 5:14pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/3 "2020-08-29T17:14:51Z")
**Update:** The wrapping infrastructure does not detect that our custom classes should be wrapped as VTK classes.
### Details below
It turns out that with `VTK 8.2.0`, the custom class wrappers are properly generated and ends up calling `PyVTKClass_Add` that is responsible to update the `vtkPythonMap` singleton by calling `vtkPythonUtil::AddClassToMap`:
```cpp
// Libs/MRML/Core/vtkMRMLScenePython.cxx`
[...]
PyObject *PyvtkMRMLScene_ClassNew()
{
PyVTKClass_Add(
&PyvtkMRMLScene_Type, PyvtkMRMLScene_Methods,
"vtkMRMLScene",
&PyvtkMRMLScene_StaticNew);
[...]
void PyVTKAddFile_vtkMRMLScene(PyObject *dict)
{
PyObject *o;
o = PyvtkMRMLScene_ClassNew();
if (o && PyDict_SetItemString(dict, "vtkMRMLScene", o) != 0)
{
Py_DECREF(o);
}
}
[...]
```
whereas when building against **`VTK 9.0.20200825`** , the following wrappers are generated:
```auto
// Libs/MRML/Core/vtkMRMLScenePython.cxx
[...]
void PyVTKAddFile_vtkMRMLScene(PyObject *dict)
{
PyObject *o;
o = PyvtkMRMLScene_TypeNew();
if (o && PyDict_SetItemString(dict, "vtkMRMLScene", o) != 0)
{
Py_DECREF(o);
}
}
[...]
```
---
### Author:  [@jcfr](https://discourse.vtk.org/u/jcfr)
#### Post date: [August 29, 2020, 5:21pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/4 "2020-08-29T17:21:01Z")
Thanks for following up with such a detailed answer, that is helpful.
> The old “PythonD” libraries relied on the system loader to ensure that dependent libraries were loaded
For legacy reason, our custom wrapping infrastructure still generate the `PythonD` library for our custom VTK python modules. I will have to also address this.
> Another possibility, though unlikely, is that multiple inheritance is gumming things up. Do your custom-wrapped objects use multiple inheritance?
Our custom classes are “classic” objects that only derives from `vtkObject`
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [August 29, 2020, 5:23pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/5 "2020-08-29T17:23:03Z")
In that case, the problem is related to the handling of hierarchy files by your customized cmake scripts. Look at the `.args` file (response file) for MRMLCorePython to make sure that the `--types` option is set correctly.
E.g. when wrapping vtk-dicom, the cmake-generated .args file contains these:
```
--types '/work/vtk-dicom-build/lib/vtk/hierarchy/DICOM/vtkDICOM-hierarchy.txt'
--types '/work/vtk-build/lib/vtk/hierarchy/VTK/vtkCommonMisc-hierarchy.txt'
--types '/work/vtk-build/lib/vtk/hierarchy/VTK/vtkImagingCore-hierarchy.txt'
--types '/work/vtk-build/lib/vtk/hierarchy/VTK/vtkIOCore-hierarchy.txt'
```
---
### Author:  [@jcfr](https://discourse.vtk.org/u/jcfr)
#### Post date: [August 29, 2020, 5:33pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/6 "2020-08-29T17:33:08Z")
> [@dgobbi](#):
>
> Look at the `.args` file (response file) for MRMLCorePython to make sure that the `--types` option is set correctly.
Looks like we have the expected info:
```auto
// Libs/MRML/Core/MRMLCorePython.Debug.args
--hints "/home/jcfr/Projects/Slicer/Libs/MRML/Core/Wrapping/Tcl/hints"
--types "/home/jcfr/Projects/Slicer-Debug/Slicer-build/MRMLCoreHierarchy.txt"
-D"PYTHONQT_USE_RELEASE_PYTHON_FALLBACK"
[...]
-I"/home/jcfr/Projects/Slicer-Debug/Slicer-build/Libs/vtkTeem"
[...]
```
```auto
// /home/jcfr/Projects/Slicer-Debug/Slicer-build/MRMLCoreHierarchy.txt
[...]
vtkMRMLScene : vtkObject ; vtkMRMLScene.h ; MRMLCore
vtkMRMLScene::NodeReferencesType = std::map > ; vtkMRMLScene.h ; MRMLCore
vtkMRMLScene::SceneEventType : enum ; vtkMRMLScene.h ; MRMLCore
vtkMRMLScene::StateType : enum ; vtkMRMLScene.h ; MRMLCore
vtkMRMLScene::Superclass = vtkObject ; vtkMRMLScene.h ; MRMLCore
[...]
```
Something is preventing the setting of `is_vtkobject` from working as expected …
I will make sure that the wrapping tool is invoked with the expected argument.
>
---
### Author:  [@jcfr](https://discourse.vtk.org/u/jcfr)
#### Post date: [August 29, 2020, 5:35pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/7 "2020-08-29T17:35:38Z")
Should the `--types` for all VTK dependencies be listed in the response file ?
Instead of:
```auto
// Libs/MRML/Core/MRMLCorePython.Debug.args
--hints "/home/jcfr/Projects/Slicer/Libs/MRML/Core/Wrapping/Tcl/hints"
--types "/home/jcfr/Projects/Slicer-Debug/Slicer-build/MRMLCoreHierarchy.txt"
[...]
```
should I get something like
```auto
// Libs/MRML/Core/MRMLCorePython.Debug.args
--hints "/home/jcfr/Projects/Slicer/Libs/MRML/Core/Wrapping/Tcl/hints"
--types "/home/jcfr/Projects/Slicer-Debug/Slicer-build/MRMLCoreHierarchy.txt"
--types "/home/jcfr/Projects/Slicer-Debug/VTK-build/lib/vtk/hierarchy/VTK/vtkCommonMisc-hierarchy.txt"
...
[...]
```
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [August 29, 2020, 5:37pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/8 "2020-08-29T17:37:24Z")
The following, by itself, is not sufficient because it only traces back to vtkObject:
```
vtkMRMLScene : vtkObject ; vtkMRMLScene.h ; MRMLCore
```
It is necessary to trace all the way back to vtkObjectBase, so the following must also be present in one of the hierarchy files provided via `--types`:
```
vtkObject : vtkObjectBase ; vtkObject.h ; vtkCommonCore
```
So those other hierarchy files are probably necessary.
---
### Author:  [@jcfr](https://discourse.vtk.org/u/jcfr)
#### Post date: [August 29, 2020, 5:41pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/9 "2020-08-29T17:41:24Z")
> [@dgobbi](#):
>
> So those other hierarchy files are probably necessary.
That makes sense and is likely the issue. I will make sure the expected `--types` are listed and report back.
Thanks for the help 🙏
---
### Author:  [@jcfr](https://discourse.vtk.org/u/jcfr)
#### Post date: [August 29, 2020, 8:53pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/10 "2020-08-29T20:53:36Z")
> [@jcfr](#):
>
> I will make sure the expected `--types` are listed and report back.
That was the issue. For future reference, see [https://github.com/Slicer/Slicer/pull/5141/commits/473ef80b7f1f2fb055ff61e23417f0403f5f38cd](https://github.com/Slicer/Slicer/pull/5141/commits/473ef80b7f1f2fb055ff61e23417f0403f5f38cd)
@dgobbi I also added you as co-author of the commit. Thanks again for the prompt help.
After “merging” the `PythonD` with the `Python` library, Slicer now builds and starts.
We are getting there 🔥🥳
---
### Author:  [@pieper](https://discourse.vtk.org/u/pieper)
#### Post date: [August 29, 2020, 8:56pm UTC](https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100/11 "2020-08-29T20:56:05Z")
Nice work @jcfr and thank you @dgobbi! 💯