Found via `codespell -q 3 -S *.po,./po,*.min.js,./ChangeLog*,./NEWS,./borrowed,./doc/README*,./AUTHORS,./libgnucash/tax/us/txf-de*,./data/accounts -L ans,ba,cas,dragable,gae,iff,iif,mut,nd,numer,parm,parms,startd,stoll`
The Book Options, counter formats were being stored under the 'options'
tree but need to be stored in the 'counter_format' tree similar to the
'counters' tree.
.
Because March has more days than February the previous month offset was
getting normalized back to the current month--th 29 February this
year is really 1 March, so normalizing before setting the day caused
begin/end previous month to return the begin/end of the current month.
That probably happened on the 31st of May, July, October, and December
as well, I just hadn't managed to test on those days. Switching the
normalization to after calculating the day of the month broke the
previous quarter calculation because now the month was out of range, so
normalize month & year first.
Separate the "All noncurrency" convenience category in the commodity
selector and the default non-commodity namespace proposed by the QIF
importer because they have different functions.
Also remove the namespace guessing code from qif-dialog because with
only one default non-currency namespace there's nothing to guess.
The changes 09296dfb96, 1373233cd0 and 189db58e6 had caused
inconsistencies. Best restore original guile variable names using
underscore, bound to strings instead of functions returning strings.
When Gnucash is run in Hebrew which is a RTL language, on the accounts
page the tree view is displaying the required number as the following...
TreeView entry is '1,500.00 ₪' or '-1,500.00 ₪'
TreeModel string is '₪ 1,500.00' or '₪ 1,500.00-'
This seems to be down to the GTK 'Unicode Bidirectional Text Algorithm'
which is changing the representation of the model string based on the
first strongly typed character, in this case the Israeli shekel sign.
To fix this, when creating the displayed monetary amount insert a BiDi
ltr isolate uni-character at the start of the string.
Converting them to pointers for Scheme to use. Prevents
dangling pointers when the user deletes a QofInstance as long as the
Scheme report code re-fetches its pointers from the options when it's
regenerated.
The original merge was of a PR based on master into maint, bringing
along all of the development changes in master along with it. We don't
want that so the merge was reverted and the PR's two changes
cherry-picked in. That fixed maint, but then the next regular merge of
maint into master naturally included that revert commit undoing the
changes in master. Not so good. Reverting the revert, this commit,
restores the changes, albeit with messed up history.
Instead of GncOptionUIType, mostly. We still need to do that to tell apart
commodities and currencies from other QofInstances.
Allows compile-time dispatch for most types.
because object may become stale if UI is used to delete it, leading to
stale pointer and segfault. storing guid is safer, and will return
null if budget is deleted.
These functions were used to (optionally) reverse amounts according to
whether the feature GNC_FEATURE_BUDGET_UNREVERSED was set. They are
now obsolete because code will now assume feature is set for all
loaded datafiles.
And use serialize to create values for gnc:generate-restore-forms and both
of them for the meat of the stream functions.
This fixes in particular QofInstance serialization where passing the
option value directly to scheme format resulted in a notation about
a swig pointer instead of the desired GUID string or commodity namespace
and mnemonic strings.
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.
