Implementing my own plugin, I'm starting to find settings somewhat confusing - the UX is not intuitive.
The Settings modal dismisses when I click anywhere outside of it as data-backdrop="static" is not used.
This means I can make changes, not hit the save button, and easily dismiss the modal without being reminded to save.
But if I do that, and go back to my settings, I'll see that any changes I've made are still there, so I guess it did save, right? There weren't any warnings about unsaved changes, and it all looks fine. I didn't need to press the Save button.
Except that, after your next restart, you'll find all of your settings reverted - because you didn't hit save.
It's also unclear when a settings change applies. Is it immediate? On Save? On restart?
While I build my plugin, I have no idea which behaviour I'm supposed to implement to conform with the above, or even if I should conform with this.
I think a sensible approach would be:
Prevent the Settings modal from being dismissed unless it is an explicit dismiss (the Save button or Close button).
Do not apply or save any settings until the Save button is used (this would solve some other problems around refreshing processes multiple times while the user edits multiple settings).
Add a cancel button to explicitly allow the user to leave the settings modal and forget any changes they've just made
Add a verification prompt on the close button when there are unsaved changes, and forget the changes if the user confirms.
Add a bootstrap style alert to the top of the settings modal remind the user that they have unsaved changes.
I think those are good points/ideas. You should post it as a feature request on the issue tracker. There are ways in which to implement this yourself within the javascript callbacks onSettingsShown and onSettingsHidden callbacks for resetting the settings to previously settings. There are also callbacks for onSettingsUpdated which allows to detecting changes, etc.
My advice is not to try fixing the behavior in your own plugin. This will result in your plugin behaving differently from all other plugins, and as a result make behavior even more unpredictable.
Fix OctoPrint, make a PR, and all plugins will benefit.
Totally agree with @fieldOfView! Make a PR so that everyone can benefit from it. It is really annoying that you can click outside the settings-dialog and the box is closed without a warning.
A small improvement could be to just prevent outside clicking...change detection could be a second part.
Because you ask:
It's also unclear when a settings change applies. Is it immediate? On Save? On restart?
The values were saved after clicking the save-button (storing the values in the file "config.yaml").....normally....but for e.g. a plugin which have a kind of table-values, these could be saved after entering. It is depending on the implementation of the custom plugin-setting.
And by the way, I you want to do more improvements about the settings dialog....what about a reset-settings button. See Reset to Default-Settings of a Plugin
"Use your own dog food".....I give you the advice to create a PR, but I didn't
All of my plugins use the reset-feature and "I can't live without that feature".....well... maybe I will also create a PR.
Isn't that basically what the clear settings button does from plugin manager now? Erasing the settings basically defaults them back to what's in your get_settings_default function.
I'd have a conversation like this with my Head of Design and Architect if I were trying to simplify this:
If we remove the ability to click outside the settings modal to close it, does the user have other ways to achieve the same thing? Yes, they could click the close button at the bottom or the cross in the top right
Are the alternatives intuitive? Yes, it can't get much clearer than X and Close, and they're also a single click each
What's the cost of making this configurable? Is it worth it? We'd have to implement another setting, and the modal would need to be aware of it. It's not a lot of work, but we shouldn't add options for the sake of it, and it clutters the interface, distracting from more important configuration. Making it configurable would make the behaviour even more confusing, because it may be inconsistent across OctoPrint instances
You are forgetting the cost to my sanity when I change established behaviour and then get to spend the next weeks with getting personally attacked for it (and I'm not exaggerating here).
Would it totally make sense to change default behaviour here? Absolutely. Is it worth it to me personally to risk the backlash of that? To be honest, nope. I already have enough on my plate as is. I'm happy to put the foot down on important matters, but this doesn't feel like it's worth getting abused over.
