We are open to any suggestions. These problems seem simple, but actually it is really hard to come up with good solutions.
There are a couple of somewhat independent questions/issues.
- Node name suffices are always incremented until the scene is closed
Current behavior: If you load nodes from the same filename then numerical suffices are added to guarantee unique name in the session. Higher suffix always mean that the node was loaded later. Counters are reset when the scene is closed.
What behavior would you prefer instead?
Option A. We could reuse old node names every time. For example, if you have CT, CT_1 CT_3, CT_4 and load a file CT then the node could be named as CT_2. I don’t think it would be any better than CT_5. Actually, CT_5 name would more clearly reflect that this image was loaded later. Not reusing names immediately is also safer, because there is a lower change that the file already exists.
Option B. We could check if there is any node by a similar name (nodename_someinteger) and if none found then restart the counter. This would not be as risky as Option A, but this kind of complex heuristics could be quite hard for users to understand. For example, how long it would take for a user to figure out that if you have still have “CT_3” node in your scene (after loading “CT” file 8 times, but deleting all of them except one) then your “CT” file is named “CT_8”; but if you removed “CT_3” node and then then load “CT” file then it is named simply as “CT”?
Any other options?
- Output file name is automatically updated to match node name
This mechanism was implemented because lots of users complained and they mixed up and/or lost data because fixing node names in the scene did not fix file names. You can easily imagine how bad it is if you rename your nodes in the scene but file names still remain the same.
The solution to this issue was to update filename automatically from node name, which created unwanted, but less sever side effects than the original problem. For example, users that realized that they didn’t like the file name changed it in the save dialog but next time they saved the scene it got reverted to the node name.
Any suggestions are welcome for softening this side effect (without introducing other issues).
- Scene saving and export is not separated clearly enough
Saving: save everything in the scene so that the current state can be restored without any change or loss of information.
Exporting: save a few nodes to a certain folder in some chosen file format, potentially in a lossy format.
Currently, the save dialog serves both purpose. Saving in mrb format saves the scene, but it is slow and takes lots of space for large data sets. Saving to individual files can be messy due to automatic filename changes (see issue 2), choice of various file formats, folders.
Suggestions are welcome how to make things simple things simple to do, but still allow to do complex things.
- If multiple nodes have the same name then it is hard to know which one is which
Before we had subject hierarchy, we could only rely on a node’s name to identify it. At many places we still use a simple node name combo box for selecting inputs/outputs.
The automatic node suffix mechanism reduces the chance of having many nodes with the same name, but it is still possible.
A potential solution instead or in addition to automatix suffices could be to change the node selector to always show a subject hierarchy tree. Then node names could be the same and they could be distinguished by their parent folder. There could be name clashes when the scene is saved (unless subject hierarchy folder name is used as subfolder name by default).
Maybe instead of brainstorming about all kinds of possible solutions, we could converge to meaningful improvements faster if you could describe your typical workflows: what data sets you load, how you process them, what do you want to export/save. We could then focus on finding solutions that make all the described workflows as effortless to do as possible.
