'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).
The order in which cmake processes subdirectories in gnucash
matters because that also defines the order in which install
rules will be executed.
We have an install rule to compile the install gschema files.
That rule has to be run after all gschema files are installed.
Considering how our code is organized that means directory
gnucash/gschema should be processed after gnucash/import-export.
That requirement was incompatible with how migratable-prefs.xml
was generated (it required the exact opposite processing order).
This conflict causes gnucash to crash on startup because not
all gschema files are compiled as they should.
The changes in this commit should fix this.
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.
They are unused by GnuCash except for migrating their
values to the newer equivalents. For simplicity they
are added to the main deprecated schema file. They
will be fully removed in a future major release.
b2b879211 had modified totals_cols_list from g_list_append to
g_list_prepend and g_list_reverse. this assumed that it was already
initialized in reverse. this commit fixes it to ensure
gnc_budget_view_refresh is processing the reversed totals_col_list.
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.
