See design task T64591.
Currently looks like this:
If auto-save is off, the Save Preferences button is then back in the top level.
I actually prefer something like what @Harley Acheson (harley) and @Brecht Van Lommel (brecht) suggested. Having the button grayout or become available when you changed something is important feedback.
The extra menu lets you see and fit more options like reset, save or export whatever we want to add in the future. But the main action available is clear and communicated.
Not seeing when revert greys out has the down side you don't know if the preferences are changed or not.
It's disputable of that's important for users, if it's not, we could check if "Developer Extra's" is enabled. Showing some extra label if it is - since this is helpful to detect times when is_dirty isn't set when it should be.
As has been mentioned on T64591: Preferences UI for Save/Revert/Reset, you can "Revert to Saved", which will change the auto-save preferences value, something which can go by unnoticed with this patch.
Note that my mockup this morning was hastily-made and not completely thought through. I think my own ideal pattern would look more like this:
I wasn't completely wedded to the ellipsis and we don't use that elsewhere. And I think the menu items should be static regardless of the settings. The only thing that would change is the button, based on the state of auto-save.
Added greying out of the Save Preferences button, so that you can see if the preferences are 'dirty', ie that changes have been made.
When no changes have been made:
When changes are detected:
This information is only really needed when Auto-Save is off, and now you can see it then.
@Harley Acheson (harley) I was not able to recreate the single arrow button style for the menu, because of the stretchy layout here.
Find the button moving inside the menu based on another option in the menu odd/annoying.
Rather just have the button there, even if you wouldn't necessarily use it frequently with auto-save, it's can still be useful.
If a Save button is there, I expect most users will press it every time to ensure they don't lose changes, even if that's not actually needed. And that then defeats the purpose of autosaving.
It's definitely what I would do in another application if there was a Save button in a dialog.
It's one of the reasons, but not the only one.
Even worse I think is that the presence of the save button makes it seems like it won't save if you don't press it. So you might make changes assuming they won't get saved, and accidentally overwrite preferences you wanted to keep.