While I do like now that on a “Quit” I am not prompted to save any patches that only had sub-patches opened or closed, that unfortunately means all explicit changes I have made in the visibility of sub-patches can only be saved by going through all the parent patches and saving them one-by-one, and there is no longer any indicator of what those were. Information that I care about, which patches are visible, is being lost.
For example, in the attached zip, if I close the bottom-most patch (2) and do a “Save” on the top-most, that state is not saved. I have to know that patch 2 was in patch 3, open 1, then 3, save it, and then exit. In even moderate to complex patches this rapidly becomes incomprehensible.
So I suggest that an explicit “Save” means that I really want to save the full patch state, and it does a save of the full state of the patch hierarchy, by in that case doing the old behavior of prompting for saving those patches where sub-patch visibility has changed. Or add a new “Save Visibility” option to the menu. Otherwise the new behavior is actually much more of a pain to me than a gain. Thanks devvvvs!
The latest alpha comes with “Save All Changed” (Alt-S) and “Save all” (Ctrl-Alt-S). Using the latter just saves every patch, wehter or not marked as changed and should cure the pain when you actually want to commit to a window layout. Does that work as expected?
Yes that will address the specific problem, but if I understand you correctly, it does so at the expense of playing havoc with any revision control system or folder comparison system if indeed EVERY patch (including those in the vvvv distribution) is saved.
So would in fact EVERY patch get a new time stamp and possibly changed contents? If so then suddenly every SVN commit becomes a massive operation, and tracking meaningful changes will become very difficult. If that is the case then it would be a huge and unworkable hit in my workflow.
Could there be a new “save visibility state” option instead, that does the old behavior? Thanks @gregsn!
Well the old behavior did not only the save visibility state. It just flagged files as changed more often. Managing a second flag is possible i guess, but not for the upcoming release.
But for future plans: saving patches flagged as changed by that second flag should still save the whole patch as is. Managing a second “xml description” of the patch that only tracks layouting changes is not what we want. It comes with the risk of loosing information when you also did some other changes that you forgot about while in a potential “save layout only” process.
So i think it’s really only about having the old behavior as a second shortcut.
But for now: i was hoping it should not save the readonly patches that come with vvvv.
Yes, that’s what I was really talking about, the old behavior as another option, perhaps “Save all changes” vs. “Save All”, as I will NEVER use a true save ALL, and in fact even doing it accidentally could make a huge mess for me and I expect anyone else using any kind of version tracking (which everyone does, right? (:^P)).
