Save with extension

[audrow]

Currently, when one saves a world, no extension is added unless the user types it out. Then when one goes to load a world, the extension must match a small list of extensions for it to be loaded.

Rather than have everyone go through the code, I figured to add the extension, if the user didn't type it out, so that the file can then be loaded easily.

[luca-della-vedova]

This is very nice and I actually ran into this a few times so thanks a lot!
I gave it a try and it seems this would do a naive "append the extension", the problem with that is that we use a .building.yaml extension for legacy projects so test.building.yaml is saved as test.building.site.ron.
Would it be possible to make sure the whole old extension is stripped and the project is saved as test.site.ron instead?

[audrow]

Would it be possible to make sure the whole old extension is stripped and the project is saved as test.site.ron instead?

Yup, this should be working now 👍

[luca-della-vedova]

I noticed that because of the way save events are sent there is a bit of a disconnect between the name of the file that is saved and the DefaultFile component (to be honest it also exists without this PR but this makes it more noticeable). I would expect the behavior of saving to be similar to how a classic editor would be, so that once the project is saved the project's default file is set to the newly saved path. It currently will print the conversion warning every time a .building.yaml project is saved until the project is closed and the .site.ron file is opened.

I wonder if we should update the DefaultFile component of the Site that is being saved to reflect the latest file that it was saved to, so that every subsequent Ctrl-S / Save will save to the last file that was specified (or in this case autocalculated).
What do you think?

[audrow]

I wonder if we should update the DefaultFile component of the Site that is being saved to reflect the latest file that it was saved to, so that every subsequent Ctrl-S / Save will save to the last file that was specified (or in this case autocalculated).

That seems like a good idea to me.

[mxgrey]

I've push some changes that address the DefaultFile concern, which is definitely important.

Changing DefaultFile led me to realize another problem: We need to change the paths for all local relative-path asset sources. So I made a change to account for that.

...which led me to uncover a panic hazard which can happen if the AssetSource of a child visual within a URDF is changed at the same time as the AssetSource of the URDF model itself. To deal with that I had to introduce a ModelTrashcan that lets us defer deleting asset trees until asset modification commands have finished flushing.

Anyway I think this PR is ready to go now, after those unexpected complications 👍