Will be discussed during March 19th 2013 Developer Hangout. See http://www.slicer.org/slicerWiki/index.php/Developer_Meetings/20130319

1) Here the problem is that once saved, the transform node is associated to a storage node which contains the filename. If you change the name of the node, the filename can't be changed, because there is no file yet with the given new filename.

2) The underlying data has not been changed, therefore there is "no need" to save it. While I understand your workflow, I believe marking the transform as modified just when the node is renamed could confuse other users in different workflows. I suggest we keep the current behavior. It should stay "simple" to understand and not have exceptions.

@Julien: As a side question, would it make sens to have a storage node systematically created when a transform node is created ?

Hi jcfr & finetjul!

I played around a bit more with the basic functions of file reading and writing.

I had earlier run into other problems in this area -- having tried to avoid diving into Python scripting, because my needs were really simple. (Scripting turned out to be rewarding, though!)

When I started, I just wanted to experiment with a few matrices for gantry tilt unskewing: I needed one for the unskewing and one for transposing axes. And I needed to compose them of course. I also tried to multiply a little correction matrix onto a registration transform -- for playing around. The kind of stuff that 3D Slioer probably should allow a user to do easily.

I ran into a lot of problems because of the complexity of the node to file mapping. "Simple" as finitjul writes isn't quite the right word in my experience (which is limited admittedly!). Out of my confusion has arisen the following understanding:

Basically, the design seems to be to avoid node name collisions, whereas file name collisions are ignored or encouraged. For example, I was stumped when I tried to re-read my unskew matrix from file "unskew.tfm" : 3D Slicer insists on creating a new node called "unskew_1". Now we have two mrml nodes that map to the same file object, a m:1 (many-to-one) correspondence from memory to disk! That's kinky I'd say. I'd like to ask whether you really mean to do this? Same thing with the rename operations: it creates a m:1 correspondence after you use the original name again (unless you explicitly rename it -- but at first you'd think the node is gone because you'd have to click "Show options" in the Save Scene box to see that the old filename is associated with renamed node...!)

An exception to "avoiding node name collisions" is if a user is explicitly renaming a node to something that already exists: in that case in Slicer you're not trying to maintain an invariant that a node name is used only once.

So I don't know what to say because I'm new here, except perhaps to state again that having a dead-simple "save as" semantics would be much simpler in practice, at least as I've experienced it. Similarly, the "open" semantics should overwrite the current object after prompting, just like in any other application. And, again for consistency with usual apps, I'd write the object out to file as soon as it's created.

So to jcfr's point: yes if the storage node was just created at transform node creation time (and initialized with the new name) then that'd be perfect although I think there'e connected issues that probably should be explored as well.

Sorry for the lengthy response, perhaps I should have replied on the developer's list? I do have the feeling that there's something basic I've missed so I stay diffident!

(BTW, I'd like to point out that renaming a node doesn't even mark the scene as "modified". It should I think.)

This issue will be discussed during next week Hangout (August 6). See http://www.slicer.org/slicerWiki/index.php/Developer_Meetings/20130806

To join hangout, be sure to join the Slicer G+ community so that you can be invited to the hangout. See http://www.slicer.org/slicerWiki/index.php/Developer_Meetings

I'm marking this resolved because I think it is the same underlying issue as 0002326. Hopefully the fix for that also addresses this use case correctly.

Closing resolved issues that have not been updated in more than 3 months