I'll check how I can change it so that invoke and exec still work as before.
Where do we rely on exec not doing any user interaction? The limitation makes sense, I'm just not sure where we rely on it. It seems to work well. Should there be an assert when exec does not finish or cancel or pass through?

When exec is not allowed to do user interaction, we probably have to call invoke more than once or use modal somehow. In any case, the file selector and confirm dialog have to be updated, so that they don't always call exec.

In D4829#110937, @Jacques Lucke (JacquesLucke) wrote:

I'll check how I can change it so that invoke and exec still work as before.
Where do we rely on exec not doing any user interaction? The limitation makes sense, I'm just not sure where we rely on it. It seems to work well. Should there be an assert when exec does not finish or cancel or pass through?

The automated tests and render farm scripts assume exec has no user interaction. There could be an assert when exec returns running modal.

Good, should I commit this in the current state?

Possible improvements that could be made before (or after) the commit:

1. Use a blocking dialog similar to the confirm quit dialog.
2. Move the generic state management somewhere else.

Blocking dialog
I talked about that with @William Reynish (billreynish), yesterday. We think it would be good to have Cancel, Don't Save and Save fields. When the file has not been saved before, a file browser will open to select the save location. In that case, the new file won't be opened afterwards. The user would have to restart the file-opening-procedure. This is because it could be very confusing (and currently technically impossible) to open two separate file browsers with the same operator (as part of a multi-step-interaction).

One issue I'm not sure how to solve yet is how to forward the operator settings. I think I'd have to make a copy of the IDProperties * and pass it as argument to the blocking dialog. The problem is that I don't see how this would be freed afterwards.

State management
If we need this mainly comes down to two questions:

• Do we expect that more operators need similar multi-step-interactions in the future?
• Do we expect that the operator system will be updated before we need this functionality in more places? Note: I'm don't know how the ideal operator system would look like to support this functionality natively.

Here's how the dialog could look:

Basically it should be identical with the one you see when you quit.

For the images thing, we could add a string to clarify that it also affects X amount of image files, if that is the case:

Here I have removed the icons in the buttons and made the 'active' button more prominent, but those are just stylistic changes. The important part is that it should be consistent with the Save Prompt that appears when quitting.

Edit: even more terse version:

I think it's fine to commit in this state and continue improving.

For the images there could be a checkbox, so you can choose to save them or not.

A version with a checkbox for saving images:

Personally I have a slight preference for this to just be a preference in the Save & Load Preferences, and that the dialog just tells users what will happen. Saving the images is almost always what you'd want anyway, and this way the text string can be more informative about the number of images to be saved, while keeping the dialog as simple as possible.

So, this very same dialog will be the one that will appear when you do File->New, or when opening a blend file on top of an unsaved project, right?
If not, why not? This seems to be the perfect dialog for that. The current "ok dialog" is not efficient and it's very easy to miss.