"Auto-increase name support for output filepaths" is what we should have, but this isn't what this patch does? This patch just adds the -+ buttons back the name field in the file browser, as a shortcut to manually increase/decrease the number in the file name. You got me excited too early there :)

To be clear: I'm not against adding the -+ buttons I think they can be useful. But it's just duct tape for a bigger issue, a real usability horror that we ignore entirely: The fact that Blender silently overrides files by default. Every time Hjalti renders the edit, he has to remember to go the the output settings and change the file name. (What's the point in having Blender automatically save renders then? Might as well pop up a file selector at render start then.) If he forgets to do this a version of the edit will be lost, unless backed up externally or committed to the SVN repository. Are we seriously suggesting it as solution to make this manual process a little bit faster?
Nothing in Blender tells users about this behavior. They have to learn that they have to do this every time through painful experiences. There was a time when render buttons and output settings were closer together, now they are at quite different places.

An option to automatically increase the video file number shouldn't be difficult to add.

Hi Julian, thanks for looking at the patch.

"Auto-increase name support for output filepaths" is what we should have, but this isn't what this patch does?

Indeed. Patch description updated.

It is just duct tape for a bigger issue (...)

I get it, and I don't disagree with the potential bigger issue. That said it is a good duct tape, one that relies on having the users in control, and help them in the process.

Besides, users were relying on this before and this got no replacement.

What's the point in having Blender automatically save renders then? Might as well pop up a file selector at render start then.) If he forgets to do this a version of the edit will be lost, unless backed up externally or committed to the SVN repository.

Are we (...) suggesting it as solution to make this manual process a little bit faster?

I'm suggesting to treat the file output as any other "Save As" file browser. If we have +- in the other cases for convenince I believe the same reasoning applies here. Even if in the future we get a more sophisticated auto-save option by the way.

Nothing in Blender tells users about this behavior. They have to learn that they have to do this every time through painful experiences. There was a time when render buttons and output settings were closer together, now they are at quite different places.

I don't see how this is related to this patch.

Adding a PROP_FILEPATH_OUTPUT doesn't seem correct, adding a new sub-type only to tweak behavior of the file-browser for an existing sub-type.

Something very similar to this has come up a while ago, where additional information about what how the path is expected to be used was to be added to RNA.

See this reply D13937#391107 (and the one below), this is a topic I discussed a while back with @Bastien Montagne (mont29) and I think the suggestion there applies to this patch too.

Long term this allows RNA properties to control how their file selector is activated without having to add sub-types or hard coded flags each time.

In D15968#434137, @Julian Eisel (Severin) wrote:

But it's just duct tape for a bigger issue, a real usability horror that we ignore entirely: The fact that Blender silently overrides files by default. Every time Hjalti renders the edit, he has to remember to go the the output settings and change the file name. (What's the point in having Blender automatically save renders then? Might as well pop up a file selector at render start then.) //If he forgets to do this a version of the edit will be lost, unless backed up externally or committed to the SVN repository.

The same argument could be made that any .blend file save, and image texture save, USD file export or physics cache bake "silently" overwrites the data and loses the previous version. It seems odd to me to make that argument specifically for render output which is only a result of the state of the .blend file.

I can see the argument that ideally there would exist some automatic versioning for all production files, or that it would be useful for some workflows to auto increment a number in the filename on every render. But overwriting the previous render output seems reasonable default behavior used by many 3D apps.

In D15968#434808, @Brecht Van Lommel (brecht) wrote:

The same argument could be made that any .blend file save, and image texture save, USD file export or physics cache bake "silently" overwrites the data and loses the previous version. It seems odd to me to make that argument specifically for render output which is only a result of the state of the .blend file.

In all these cases there is an explicit user action to save a file as far as I can tell. I think we do have some other cases where you define an output directory that Blender "streams into" though. I would look at it on a case-by-case basis if overwriting by default is a good idea or not.
Also, I'd actually look at it the other way around: The rendered output is pretty much the output you work for, while the other data is more or less fragments you create along the way. In that sense it's more important to keep versions of the render result than the other files. Back when I was actually using Blender a lot I always wanted to keep all rendered versions around.

I can see the argument that ideally there would exist some automatic versioning for all production files, or that it would be useful for some workflows to auto increment a number in the filename on every render. But overwriting the previous render output seems reasonable default behavior used by many 3D apps.

I may very well be wrong but I think in other apps you usually have some rendering dialog where you see the output path together with the render settings. It doesn't have the discoverability problem I'm suggesting we have here. And it's not something you consciously have to remember to do, because the software "lays it out under your nose".
Of course there are also valid reasons to override the file, it should remain an option.

In D15968#435528, @Julian Eisel (Severin) wrote:

In all these cases there is an explicit user action to save a file as far as I can tell.

Pressing render animation is the explicit action, just like pressing bake, save or export.

I think we do have some other cases where you define an output directory that Blender "streams into" though. I would look at it on a case-by-case basis if overwriting by default is a good idea or not.
Also, I'd actually look at it the other way around: The rendered output is pretty much the output you work for, while the other data is more or less fragments you create along the way.

Files streaming from one thing into the next is how pretty much everything works in a pipeline. Even the rendered output is likely to stream into something else again, be it for compositing, grading, compression, upload, etc.

We should be encouraging users to think of things this way, and for example the collection I/O is a step in that direction for another area.

I may very well be wrong but I think in other apps you usually have some rendering dialog where you see the output path together with the render settings.

I don't remember e.g. Houdini or Maya working like that at least.

But I don't deny that it would be useful to have an option to auto increment the filename. Or maybe better rename the old file similar to .blend1, .blend2 (but without a limit), so that it still works for feeding the latest output into the next part of the pipeline.

In D15968#435559, @Brecht Van Lommel (brecht) wrote:

Pressing render animation is the explicit action, just like pressing bake, save or export.

What I mean is that the user will have to use the file browser to actually store a file, or at least do an explicit file save operation (as opposed to rendering animation that just happens to save files as well). Physics baking is just storing a cache, ie volatile data for performance reasons, which is totally fine to overwrite by default IMO. This doesn't even save to disk by default. For texture baking the file needs to be saved explicitly too.
But again, this should be decided on a case-by-case basis. Silently overwriting entire animation renders is still quite problematic to me.

We should be encouraging users to think of things this way, and for example the collection I/O is a step in that direction for another area.

Definitely, no argument there. We just should make careful design decisions to avoid unexpected data-loss.

I may very well be wrong but I think in other apps you usually have some rendering dialog where you see the output path together with the render settings.

I don't remember e.g. Houdini or Maya working like that at least.

Checking some public docs and videos:
In Maya the output path is mentioned quite prominently alongside the regular render settings. It also allows adding a version number (auto increased?). 3Ds Max also has the output path in the render settings, and doesn't even save files by default. And: It warns you when rendering would overwrite a file. No idea if Maya does this too. DaVinci Resolve also displays the output file name prominently, plus gives you a very clear waning popup when you'd overwrite an existing file.

So all things considered, other apps have designs in place to prevent data-loss, Blender lacks this. In Blender the render and output settings are more separate, the output path is quite hidden compared to other apps.

For what it's worth I find the flag worse than the sub-type. We're struggling with little available bits for the flags, while we have lots of space for sub-types still. Although it should be a temporary solution since D13937: UI: Interface Font Selection requires a proper design.
Either way it's acceptable to me. I think the flag name isn't clear now, noted inline.

In D15968#435712, @Julian Eisel (Severin) wrote:

For what it's worth I find the flag worse than the sub-type. We're struggling with little available bits for the flags, while we have lots of space for sub-types still. Although it should be a temporary solution since D13937: UI: Interface Font Selection requires a proper design.
Either way it's acceptable to me. I think the flag name isn't clear now, noted inline.

Agree, but there is an important difference though. We can move flags around internally (we could move this to a path-flag for e.g.), where as sub-types use a unique slot, exposed to the Python API which requires a breaking change to move elsewhere, further it makes the API marginally worse where non-obvious bugs could be introduced anyone who assumes (subtype == PROP_FILEPATH) {..} is a valid checks for file-paths.

I wouldn't mind considering a separate property flag as part of this patch, but don't find it a blocking issue either.

A different flag to eventually support things like relpath, fonts, ...?

Yes, support for relative paths is the only other flag that seems logical to add, although I think this might only be of interest to add-on developers (as in - we don't need this for Blender's internal paths as far as I know).

We might have a separate struct member for filtering, it depends if we want to support all filtering options as well as the ability to enable multiple at once.

@Brecht Van Lommel (brecht) like that?

The file browser in turn should check if the value is true rather than just if the property exists.

This was already the case in the code.