Syntona, saving Top XML behavior changes after subpatch is saved and link href is used in Top

[DoctorNerve]

Current behavior which is expected and good:
Editing a subpatch and saving Top results in edits to subpatch being saved, because the Top xml includes all units and connections required to rebuild the subpatch. So the user gets into a development cycle of editing the subpatch, jumping to Top, listening, diving back into the subpatch to make more edits, etc... and is assured that saving the Top will result in an XML that recreates latest and complete state of the work.

Here's where the trouble starts: once user saves a subpatch as a separate XML, the top patch saves a link to the subpatch filename. This is not bad, but user is unaware of this change to the XML file structure and its consequences.
Further edits by user to the subpatch are not saved when user saves the Top. User is unaware of this behavior change.
This is bad because the user expectation is that saving the Top saves all changes, so later when the user reopens the Top xml, any changes since the subpatch was saved as a separate XML are not there.

Maybe a good solution is for File menu to explicitly require the user to make a choice. There's "Save current patch (with links)" and there's "Save bundle". The former works as Save currently does, writing links when possible. The latter dives into all subpatches and puts everything into a single XML with no links. The bundle is the guaranteed-to-work recreation of current state. This would be good because it exposes the idea to the user. You might also consider disabling the "with links" save menu item, until the state of the patch is such that links will be written. So in the example above, once the user saves a subpatch, the menu item to save with links is enabled, driving the idea home.

[philburk]

This problem was made worse by the fact that the '*' in the sub patch title bar was cleared, leading the user to think the sub-patch was saved. I fixed that.

There is a potential problem from automatically saving subpatches. Suppose a patch contains three copies of the same subpatch loaded from a file. If you edit one subpatch then the loaded subpatches do not match. The user can "Detach" the edited subpatch from the file so it will be saved inline. Or the user can save it. But then when the top patch is reloaded all three subpatches will be the modified version. So we need to prevent a user from accidentally modifying a patch that is shared. Maybe we could force the user to unlock it, which would automatically detach it. This needs more thought.

For now, the user will be prompted whether they want to save the file. So the edits won't get lost.