16 Commits (47904a858ea10aeeb4fbf8deade1d2cfa320736f)

Author	SHA1	Message	Date
Geert Janssens	bdb06479e8	GSettings - fix GObject warning when old prefs-version is unset ... This will happen when current master (future 5.0) has been run at least once.	5 years ago
Geert Janssens	09b3ce2382	Revert "Add structure to map migrated preferences to old ones" ... This reverts commit c6103a5c17.	5 years ago
Geert Janssens	806d0b3157	Revert "GSettings - make most of the api private" ... This reverts commit 26b2d7ca78.	5 years ago
Geert Janssens	1d4673ed2a	Revert "GSettings - rework internal helper functions to use more C++" ... This reverts commit 24fa289952.	5 years ago
Geert Janssens	24fa289952	GSettings - rework internal helper functions to use more C++	5 years ago
Geert Janssens	26b2d7ca78	GSettings - make most of the api private ... All preference calls should happen via the gnc_prefs_... apis. The gnc_gsettings_... apis are an internal implementation of this.	5 years ago
Geert Janssens	c6103a5c17	Add structure to map migrated preferences to old ones ... 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.	5 years ago
Geert Janssens	9a465fc359	GSettings - add 'deprecate' and 'obsolete' conversions for user preferences ... '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)	5 years ago
Geert Janssens	64576f7d27	GSettings - widen scope from 'migration' to 'transformation' ... 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).	5 years ago
John Ralls	29e7b07ed3	Remove superflous schema_source left over from pasting.	5 years ago
John Ralls	8bfa5a63f2	[gsettings] Avoid crash from settings schema not being registered.	5 years ago
Geert Janssens	8ea52ae212	GSettings - run data model transations while setting up ... 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.	5 years ago
Geert Janssens	f1802b6fdf	GSettings Upgrade - add code to migrate settings ... 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.	5 years ago
Geert Janssens	f21c7b6e90	GSettings - define old prefix and check settings for the presence of both prefixes while normalizing	5 years ago
Geert Janssens	a203c5b2d5	GSettings - drop logic to relocate our settings ... 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.)	5 years ago
Geert Janssens	d1113a4534	GSettings - build as cpp	5 years ago