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
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.
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.
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.
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.
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 ?