I have been reading on singleton implementations and there appears
to be a lot of pushback against those.
We can revisit this if it turns out performance degrades
significantly by running the F::Q check multiple times.
Handle template transactions that don't have any splits with empty credit
and debit strings and those having no set transaction account.
Set the concrete transaction commodity to the first found of:
The template transaction's commodity
The commodity of the first split with a credit or debit string
The commodity of the first split.
Test these scheduled transactions:
* 2 splits with fixed amounts "123"
* 2 splits with fixed amounts "0"
* 2 splits with empty amounts ""
Verify that automatically created scheduled transactions exist.
Enables full functionality for complex-boolean and multichoice-callback
options.
Note that setter-function callback isn't used in any GnuCash code so it
is not implemented and is not present in the register-callback functions.
This scrubbing function calls xaccTransRollbackEdit which is
leaky. Instead of trying to fix xaccTransRollbackEdit which requires
superhuman skills, it's easiest to track the changes separately in a
GList, and use xaccTransBeginEdit/xaccTransCommitEdit only if
necessary.
These functions depend on both libgnc-app-utils and libgnucash-guile,
creating a circular dependency when the app-utils bindings are added to
libgnucash-guile.
With these changes the currency works but the commodity allows you to
set the commodity but will crash if you save config or leave report
open, this was tested on the 'Price scatter plot' report. Fixed with
John's commit a8e6a59
The GncOptionRangeValue can be used with integers or doubles, the
default being doubles. When used for setting the plot width/height,
integers are used so all ValueTypes need to be integers other wise
the when create_range_spinner is used you end up with the upper_bound
value being G_MAXDOUBLE, a 309 character wide spin button. To
differentiate the two, use 'set_alternate(true)' for integers.
The new plot setting does both settings, values above 100 are treated
as pixels and ones below are treated as a percentage. This means the
maximum valid setting must be higher and also the tooltip needs to be
changed.
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.
