Expose save_all_scenes method to EditorInterface

[henriquelalves]

This PR exposes save_all_scenes method to the EditorInterface class. It's a very simple change, but I don't think there were other ways to do this in the editor.

I added the documentation for this method and changed, but I wanted to propose changing save_scene to save_edited_scene (and save_scene_as to save_edited_scene_as). It's a breaking change, but the previous method names gives the wrong impression on what they do, since it's not possible to use them to save an arbitrary editor scene. Is it okay to add this on this PR, or should I ignore this?

PS: My use-case is a very simple addon with pre-configured resolutions for different mobile devices. I need to change the resolution in the inspector quickly, without the hassle of opening Project Settings multiple times, and I need the addon to reload every open scene to see the changes. Problem is, when the scenes reload, any modification not saved is lost, so I need to save them first. Before this PR, I was saving all scenes by running play and stop via code, because by default the editor saves all scenes before playing the game - but that certainly wasn't efficient nor the best way to do this.

[YuriSizov]

You need to fix the documentation. You've probably edited it manually, but the order is incorrect. Make sure to use the doctool instead of editing by hand, and then fill out the description. See this doc.

I agree that the names of the existing methods give a wrong impression, but we don't consider such breaking changes anymore, since Godot 4 is stable. That said, I think your problem can be solved if we were to expose a proper save_scene method that takes a scene resource path as an argument. Then you can use existing API to iterate over open scenes and save them one after another. But exposing existing "save all" method is fine too.

[henriquelalves]

Done!
I just added a bit on the save_scene and save_scene_as to clarify their functionality.

[Eoin-ONeill-Yokai]

This looks good to me, thanks for submitting it! It looks like some people in the repository put the "(squash)" notice at the end of the squashed commit titles though I'm admittedly not sure how rigid we are about this as a commit formatting standard.

[YuriSizov]

It looks like some people in the repository put the "(squash)" notice at the end of the squashed commit titles

That would be incorrect.

[Eoin-ONeill-Yokai]

It looks like some people in the repository put the "(squash)" notice at the end of the squashed commit titles

That would be incorrect.

Ok thanks for the clarification!

[AThousandShips]

This is caused by using squash instead of fixup, it's confusing when we say to "squash" but see the PR workflow instructions (meant that it can be confusing and think it's only squash that should be used)

[YuriSizov]

@AThousandShips Both actions are squashing commits. It's just one appends the commit message from the squashed commit, and the other drops it. But let's not derail this PR review too much, OP is completely fine here :) But it will have to wait a bit for the 4.2 merge window.

[YuriSizov]

Thanks for the rebase :) I'm adding this PR to the queue so we don't forget about it.

[YuriSizov]

LGTM. Important note that this will stop the currently playing scene.

[YuriSizov]

Thanks!