2021.09.28 Weekly Meeting

Tomorrow, we will be having our next weekly hangout at 10:00 AM ET until 11 AM ET.

Anyone is welcome to join to ask questions at https://bit.ly/slicer-googlemeet-hosted-by-kitware


Feel free to post to this thread to request/suggest a topic!

Sam and J-Christophe

1 Like

Thanks @jcfr for adding me to the agenda!

I’m planning to bring up items (3) and (8) from the list of remaining items to deal with in my pr.

(3) Adding a transform-hardening checkbox. I want to get feedback on two different approaches, one that follows precedent but is an API change, and one that keeps changes nice and localized but also less available to the rest of the application. I will describe what I mean in detail.

(8) UI considerations in enforcing file naming conventions

Should the new Markup toolbar and other changes be discussed as well? Changes to the Markups Module

I know @jamesobutler had some concerns…

I’m planning to join to hear about the export nodes PR. So I’ll be there if there’s interest in a discussion of the Markups update. I don’t think @jamesobutler is usually available at that time.

Just FYI I’ll be out this week but can join any follow ups next week or later.

That’s right. I won’t be able to attend due to meeting conflicts, but can reply on a discourse post regarding discussed Markups Toolbar improvements

I’d like to have a few minutes to present you PediGuide, the pedicle screw planning and surgical guide generator software I have been working on, and ask you a question about it.

1 Like

Summary of comments about export:

  • Rename context menu item to “Export as…” or “Export to file…”
  • Regarding (8) from the pr: a prompt would be a good way to deal with it.
  • Exporting should not use the storage node in the node. Instead it should create a new storage node and use that to write to file. This is because one often wants different a filename and directory to be remembered by the export dialog versus the save dialog. And we don’t want exporting to mark a node as “modified” for the purpose of saving the scene.
    • One idea suggested here is to keep a private copy of the newly created storage nodes within the export dialog. However, I think it might be better to make a new storage mode at every export. Saving storage nodes would not help with remembering previous settings, because we actually want settings to remembered per node type and not per node. I can explain this more clearly if someone is worried about it.
  • Regarding (3) from the pr:
    • Hardening is really more of a preprocess step than a write step, so it shouldn’t be part of the node writers.
    • The checkbox shouldn’t be in the options widget. It should be its own “coordinate system” widget in its own row. Look at the segmentation module’s “export to file” for the sorts of things that could go in there later.
    • Preprocessing is logically independent of GUI so it should be done outside of the actual export dialog widget. It should be part of the export logic handler which can be put into vtkDataIOManager or something like that.
      • It would be good if this export logic handler didn’t have to change much for exporting multiple files.
1 Like

Apology for missing the opportunity to discuss about the Markups updates, we will make sure to cover the topic next week.

Adding to the export discussion notes some additional notes from @jcfr :

  • If warnings happen, dialog should not be closed and user should have a chance to adjust options. For example, could have the following 3 choices: Proceed Anyway, Go back and Cancel
  • Setting export name should not update the node name and extension in the scene.
  • A seperate stroage node could be created. Having a private scene with nodes could be an easy way to store options for each nodes. Check with @jcfr with questions.
  • transform-hardening
    • local to the export dialog
    • or have similar approach as the “compress node”: Meaning a parameter to the ctor of qSlicerNodeWriter
    • hardening is a different pre-processing step (like unit conversion, lps → ras)
    • implement the writing logic: May be extend vtkDataIOManagerLogic ?

Thanks @jcfr! That will also give us a chance to collect some more feedback from users.

1 Like