Allows reports to derive from other reports and then change the option
default values to suit. If they change only the values and not the defaults
then it's possible to create saved report configs that don't include the
options whose values are changed to the base report's default value. See
https://bugs.gnucash.org/show_bug.cgi?id=642292.
Instead of arbitrarily using the first allowed value.
Also update tests for the Scheme type addition to
GncMultichoiceOptionChoices, intercept more cases where the value
needs to be transformed, and go back to emitting a string instead of
throwing in GncOptionMultichoiceValue::get_value when m_values has more
than one value.
Scheme can use strings, symbols, or ints as keys in multichoice options,
but C++ can handle only strings. Add conversion and tracking so that the
right key type gets sent back to Scheme.
To support a variation available in dialog-options. Even though it's not
used in any GnuCash code nor documented anywhere it might be in some
custom reports.
After getting a better understanding of how it interacts with dialog-options and
finding some additional scheme API needing implementation (exposed only in
hello-world.scm, but possibly used in user-written reports).
Creates a new file-pair, gnc-options-date.[ch]pp to separate the creation of
the static structs with the type info and strings for the various
RelativeDatePeriod values from the already too large gnc-option-impl.
Although the result is a rather C-ish design the alternative with classes
or template specializations would be more complicated and offer no
benefit.
Implements the permissible_values functions of GncOptionMultichoiceValue
for GncDateValue and provides for absolute, relative, and both
UI values for the three widget configs afforded by dialog-options.
From std::string. The consumer is a GtkWidget so we might as well do the conversion
inside the class and this will simplify adding these functions to GncOptionDateValue
in the next commit.
Separating the UI from the data model. Note that the GncOptionVariant
classes still have a GncOptionUIType member to ensure that a
GncOptionUIItem of the right type is attached.
So only GncOption and the GncOptionDB free-function interface are public.
We don't want to expose template headers widely, it would blow up compilation
times and might lead to one definition rule violations.
John Ralls