Writing a Scripted Subject Hierarchy Plugin -- documentation lacking

shai-ikko
Thu, 27 Nov 2025 13:33:42 +0000
Development

Hi,

Recently I’ve been writing an internal-use Subject Hierarchy plugin. I ran into some difficulties that stem, IMO, from lacking documentation, so I want to share what I’ve learned with a view to getting some comments and eventually improving the docs.

The first, and most important issue, is the context. For a class to serve as a Subject Hierarchy Plugin, it needs to

Be written in the main file of an Extension Module

Be named exactly as the module, with the suffix SubjectHierarchyPlugin

That is, if your module is named Kawabanga, the plugin class must reside in Kawabanga.py and be named KawabangaSubjectHiearachyPlugin.

This is followed, but not explicitly declared, in the example plugin in the script repository; that example is also a bit misleading, because it is (correctly) described as an example for a special plugin (one that operates in views, rather than in the subject hierarchy).

Other plugins which claim to serve as examples – e.g. SegmentEditorSubjectHierarchyPlugin in the sources – don’t actually follow these rules, and so they are misleading.

When fixing the documentation, we should also modernize the examples – currently, the way to iterate over children is presented in the script repository as

children = vtk.vtkIdList()
shNode.GetItemChildren(parent, children)
for i in range(children.GetNumberOfIds()):
  child = children.GetId(i)
  ...

but with modern Python and Slicer, this can be done with

shNode.GetItemChildren(parent, children:=[])
for child in children:
  ...

I will come back to this later, but wanted to raise this while fresh in mind and maybe get some feedback.

Thanks!

3 posts - 2 participants