When added, e.g. in an Advanced options section, most options are initially unchecked.
Some (roughly 20%) come up checked. One could even argue that this is a convenience.
I’ve seen some commentaries on how command line options are interpreted, for example:
Option not present => false
Option present, value is "0", "off", "no" or "false" => false
Anything else => true
but I haven’t found a discussion of how GUI should work. What seems to be happening is that default is sometimes not explicitly set to false, winds up as an empty string, so becomes true.
It should certainly be consistent, anything else is confusing.
The UI is a bit different than the commandline as there is no difference between default true and default false from a user perspective (i.e., the checkbox is either checked or unchecked by default).
The logic and options are from the commandline where the idea is to not require the user to supply input parameters when they are default. The other convention is that supplying an option defaults to true, so these two are equivalent:
--use-ssl=true
--use-ssl
This implies that all default parameters should be false, so the absence of an option would evaluate to false, and the presence of one would evaluate to true.
This logic of having all booleans default to false is not 100% consistent, but mostly it is. We should fix any remaining options that do not adhere to this, but it requires some work to make sure it does not break existing backups.
A quick look through the source indicates that only a few options are explicitly setting the “false” value, which is likely where you see the “false” value.
EDIT: All options in the “main” options file set this explicitly, but in modules, backends, etc, it is a bit more random if the option is set explicitly.
Thanks for getting a discussion going. I’m sort of hoping that other users will give UX opinions.
This confused me initially, but it might be highlighting the GUI presentation when option is picked. There’s also highlighting that default behavior occurs at multiple levels. The default documented behavior at CLI help is what happens when the option is not typed at all. Typing the option favors interpreting it as true, except for specific false values. This could be considered UX convenience:
and the small set of values that are considered false is in line with option presence favoring true, which would reduce the chance that the user would type the option, but inadvertently set it false.
The “ease of” question I wonder is whether the GUI should behave like the CLI does for boolean options. If one goes to the trouble to pick it, CLI rewards users with true, GUI goes the other way typically, because most boolean options default to false, and I’m hearing continued backing for it.
One UX reaction might be “Can’t you figure out that I want it true, after I went through picking it?” This has caused errors occasionally when user did not look closely that they need a second click.
should perhaps not be viewed as a boolean option viewer, but an option adder to override a false.
Problem with that idea is that for non-boolean options, one might pick it to see if one likes default, then if it’s favored, deleting it or leaving it as-is gives same result, ignoring rare change of default.
I think there is merit to this line of thinking. But it is a bit different then, because other options would retain the default value (e.g., enums) after being picked.
