The book parameter is only needed while fetching quotes.
In case the user passes one or more commodities to process
the book can be readily derived from the commodity/commodities.
In the other case (fetch all quotes) the user now is
required to pass a book to the call.
This code will convert the json data into GncPrice objects and add them
to the pricedb, effectively doing what price-quotes.scm does.
A few notable remarks:
- still requires plenty of cleaning up. This is the first proof of concept
- like the original scm based code, this parser completely ignores timezone
information. As it wasn't used before and nobody complained, it may not
be that important. Or it can be implemented later.
- price-quotes.scm would first check if a price already existed in the pricedb
and try to update that one instead of adding one (only if the old price's
type is inferior). However that is redundant as gnc_pricedb_add_price does
the same check. So I have omitted this extra check from GncQuotes.
- currency quotes can be inverted. I have slightly changed the way to handle
this. The perl wrapper code will simply set an "inverted" flag in that case,
but will otherwise not swap currency and commodity as it used to be the case.
On parsing, the inversion flag will cause the GncNumeric that's parsed from
the price to be inverted. As it's still a GncNumeric that shouldn't result
in any loss of precision, while keeping prices in the db always in the default
currency.
That allows the private implementation to pass a number of variables
based on various boost libraries. It's better to not have them in
the public interface to keep compilation times down.
For all but the basic check a book is required. Might
as well be able to pass it directly and store a reference
to it. That will simplify member function declarations.
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.
This rewritten version takes JSON input and spits out JSON.
Additionally inverted currency quotes will only be flagged.
The old code also swapped currencies in the result.
GncQuotes will be written towards these new implementation
choices.
At the same time do an explicit reinstantiation of quotes_cached at first use
to work around what seems to be a race condition between static instantiation
and binreloc.
This library intends to wrap Finance::Quote the way price-quotes.scm currently does.
In this first commit the library replaces price-quotes.scm's library to install
quote sources. In addition it exposes a new command line parameter in gnucash-cli
to show which version of Finance::Quote is installed on the system (if any) and
which quotes sources that verions exposes.
This comes with a few nice side effects:
* "help:" no longer needs the workaround to link directly to an anchor.
" "help:" requires the document's book id to be "index". We used to have
"index" for guide and "help" for manual. The forced alignment also
allows us to simplify the way MacOS invokes guide an manual.
This comes with a few nice side effects:
* "help:" no longer needs the workaround to link directly to an anchor.
" "help:" requires the document's book id to be "index". We used to have
"index" for guide and "help" for manual. The forced alignment also
allows us to simplify the way MacOS invokes guide an manual.
Using globs for file copying prevents cmake from discovering newly added icons.
Writing rules that explicitly use lists of icons will fix this as a new icon
in the sources will have to be added to the list and will force reparsing by
cmake. We have to maintain the lists anyway for our dist target so there's
actually no extra work involved for the devs.
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).
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.
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 list consists of old and new values for gsettings paths and keys
and will allow gnucash to migrate values from each old path and key
to the corresponding new path and key.
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.
- Remove and cleanup duplicate code
- C++-ify
- Run code in gnucash-cli commands related to reports.
Users may want to load modified report code via
config-user.scm which they want to access while
executing cli commands
There are a few subtle differences between unix makefiles and ninja
that sometimes go uncaught as the core devs usually use ninja.
This commit fixes two:
- don't depend directly on files in other source/binary directories.
Use a custom target to depend on instead
- recursively create target directories, as make doesn't automatically
- Move Macos specific bits to its own source file. As this is objective-c use .mm extension
- Use common function signature for Macos and Windows init function and include via common header file
Also properly handles the user clicking the cancel button on the transfer dialog
It will now just return to the payment window, waiting for further user input.
Changes to tip_of_the_day.list.c will now properly trigger a rebuild.
Plus a few minor assorted fixes and changes to generating the man pages
- only generate the final files in share/gnucash, not in the build directory
- gnucash-cli.1 was not installed, gnucash.1 twice
Wrapping the std::vector to hold the log flags is unneeded and actually harmful.
Just work on the vector directly. If user doesn't specify any '--log' options
the vector will just be empty.
Geert Janssens