This can be used to keep both in sync in the period between
initial migration and eventual obsolence.
Note only non-obsoleted, migrated preferences are tracked.
We don't want to resync preferences that have been
obsoleted (reset). That would nullify the whole idea
of making them obsolete for future removal.
This commit only adds the mapping, synching will follow in a future
commit.
'deprecate' is technically a noop. It serves to remind maintainers
the 'deprecated' preference is to be obsoleted in the next major
release.
'obsolete' goes one step further in that it will cause gnucash to reset
the preference, effectively clearing the value stored in the preferences
backend. This is the final phase of a preference. Following this it
will be completely removed from the GSettings schema in the next
major release.
Notes
* 'deprecate' and 'migrate' are related. Both are a reminder the
preference is to be obsoleted in the next major release. 'deprecate'
does only that though while 'migrate' will also trigger a copy of
the old value to a new location in the databse.
* This commit readds a couple of preferences that had been removed
in the past to be able to properly obsolete them (and to test
the obsoleting code)
This commit mostly changes descriptions and variable names to
use the more generic terms 'transformations' or 'conversions'.
'migration' is only one possible transform, future commits will
add others.
There are no functional changes in this commit other than
a logic inversion in parse_one_release_node. It now checks
for nodes named 'migrate' rather than for nodes not named
'migrate' (the code is adapted accordingly to match this
logic change).
We had hardcoded HAVE_HTMLHELPW to always be true so the fallback
code that's only reached when it is false was never reached.
Time to drop this dead code.
This makes sure all schema changes are in effect before
the first consumer can query them. For example this will
prevent a one-time re-occurrence of the tip of the day dialog
the first time the new migrations are run.
The rules for migration are read from an xml file. This file was
prepared in a previous commit. Future settings 'data model' changes can
reuse this code by simply adding migration rules in the xml file.
This replaces the hardcoded rules that were currently in place to
migrate a few settings from 2.6 and older to 3.0. These rules are no
longer meaningful as we require users to migrate from one major release
series to the immediate next one. So by the time the new migration rules
in this commit are applied by users they should already have run gnucash
3.x at least once. That run should have taken care of the pre-3.0
migration actions.
This was ported from GConf, but GSettings doesn't work that way.
Settings locations are defined at compile time and can't be
relocated at run time (unless you make all of the settings
explicitly relocatable. That however is not how GSettings is meant to be
used.)
The latter is the prefix format prescribed by gsettings itself. The former never
was an issue until flatpak decided to not accept the shorter prefix when
requesting a settings migration from host system to flatpak sandbox.
In order to allow for migration, keep the old schema around in
org.gnucash.GnuCash.deprecated.gschema.in
While we're at it, make the new prefix an internal implementation detail.
There's no need for it to be visible to the rest of the gnucash code.
significantly
Modify the DEBUG and PINFO macros to return unless qof_log_check is
true. Replace almost all direct calls to g_debug and g_message with
DEBUG and PINFO respectively.
Track the highest logging level sent to qof_log_set_level to provide a
short-circuit return in qof_log_check. Remove setting GNC_MOD_TESTS to
QOF_LOG_DEBUG so that the short-circuit threshold isn't defeated by
always being DEBUG.
Net result: 33% improvement in xml load times.
Removing the only use, an example in hello-world.scm. GnuCash doesn't
use this value in any of its own report options and the feature will
be removed in GnuCash 5.
Related to bug 798297 Pref "Use 24-hour clock" obsolete?.
From a Scheme alist. The vector can be used to find the scheme symbol
as a direct lookup, which isn't possible with an alist, and can be
searched for the Scheme symbol match more quickly than an alist can.
GncOptionValue<const QofInstance*>.get_value() returns a QofInstance* but
reports store them as strings, either commodity mnemonics or GUIDs.
Specialize set_value/set_default_value from scheme to handle those
possibilities.
GncOptionValidatedValue throws an invalid_argument exception if it's
fed an invalid argument. Catch that so that it doesn't crash the program.
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.
A static has to be initialized at library load and Guile
isn't necessarily running then. The singleton gets evaluated at
runtime only if the getter is called from Guile.
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.
This is a bit of a hack to handle PlotSize options. They're the only
RangeValues that use ints; the rest use doubles because the control is a
GtkSpinButton and that uses doubles. The chart code expects a pair with
either 'pixel or 'percent saying what to put in front of the number. We
hack that too: if value <= 100 then it's percent because 100px is about
3cm on modern monitors and 15mm on HiDPI ones. Bigger numbers are pixels.
This effectively reverts b7dd7f.
Note that two cases aren't handled because the types aren't GObjects and
so don't have type macros to decipher them: GncOwner and QofQuery. Since
they're not GObjects they're obviously not QofInstances either and we
need to rethink this value type a bit.
Create an alist mapping the Scheme symbols to the corresponding Swig
functions that alias the enumerations. When a symbol is received look
up the corresponding function and evaluate it, retrieving the enumeration.
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.
So that one can't instantiate an invalid constructor.
Unfortunately Swig doesn't understand SFINAE and will try to create the
invalid constructors anyway but at least this generates a compile-time
error when it tries to.
Required creating a registration class for create_option_widget
overload functions because without it the dispatch function
complained of missing symbols at link time.
So that most of the gnome-util and gnome consumers don't need to
be converted to C++.
Hide the corresponding functions in options-utils to stop the
compiler whining.
Note that this commit breaks the build but is necessary at
least temporarily to compartmentalize the changes.
Wraps creating a GncOptionDBPtr, freeing up gnc_option_db_new() to
return a GncOptionDB* for use in C code. Convert gnc_option_db_new()
calls in gtest-gnc-optiondb to call std::make_unique() as well.
Provides find_option(const char*) and foreach_option(func) for easy
iteration. find_option and find_section now return plain const ptrs
instead of std::optionals. Much less cumbersome though the compiler
won't nag if you forget the nullptr check.
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.
Simplifies the design because derived classes can have whatever save UI class
they need and implement the void(void) set_ui_item_from option and
set_option_from_ui_item with whatever functions are appropriate for
the UI class. No need for callbacks or std::function members.
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.
Implemented in gnc-optiondb.i it more clearly indicates the intended
use and restricts the access. Unfortunately further limiting the
friend declaration with #ifdef SWIG prevented the declaration from
working, raising the error "m_option is a private member of GncOption".
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.
Not everything from the 6 Book-Currency commits is removed: Switching
the Num and split-action fields and restricting edits of transactions
older than n days were included and those changes are left in place.
Some other partly-implemented features were also part of these commits
and were removed: Options for setting a default capital gains account
and currency, completion of the LIFO cap-gains policy, and creation of
a list of cap-gains policies.
If any of these are to be revived they should each be done in a separate
feature branch and submitted via Github pull request for a code review
before merging; a design discussion on gnucash-devel before restarting
work is also advisable.
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.
These add or parse the textual noise needed to replicate the Scheme options'
serialization technique of saving scheme forms for saving report options
and then evaluating those forms to restore the option values. Required for
backward saved-reports compatibility.
Added advantage that it handles (not correctly, but in the same way as
the old code) the ambiguity between a period starting or ending with
the stored value "relative . today".
The old gnc:lookup-option returned the option object so that it could be
manipulated rather than getting its value; gnc_option_value replicates
the behavior of (gnc:option-value (gnc:lookup-option)).
Replaces GncOptionValue<GncMultiChoiceOptionChoices> because having the
vector as the value obviously wouldn't work and besides it needs
additional functions.
Passing references to it to the gnc_register_option functions.
Not tested yet with SWIG, might not work.
Includes introducing fixtures to gtest-gnc-optiondb.cpp.
Provides a type and a raw pointer member with accessors. The type is one of
enum GncOptionIUType and is either VOID (for internal options that don't
get UI items) or one of the widget types specified in dialog-option.c or
business-options-gnome.c.
The objective of the free functions is to hide the GncOption from language
bindings so that the GncOptions can be moved into the GncOptionDB instead
of having shared ptrs splattered around the heap. Nearly all access to
the options can then be mediated through the GncOptionDB container.
Note that gnc_option_db_new creates the GncOptionDB on the heap and
returns a raw ptr, so it's up to the creator of the GncOptionDB to
call delete on it when it's no longer needed.
four digits in length generates an error message.
Because the grouping is off. Checking grouping on input is pointless so
just ignore the grouping separator when parsing number input.
