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.
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.
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.
Added advantage that it handles (not correctly, but in the same way as
the old code) the ambiguity between a period starting or ending with
the stored value "relative . today".
The old gnc:lookup-option returned the option object so that it could be
manipulated rather than getting its value; gnc_option_value replicates
the behavior of (gnc:option-value (gnc:lookup-option)).
Replaces GncOptionValue<GncMultiChoiceOptionChoices> because having the
vector as the value obviously wouldn't work and besides it needs
additional functions.
Passing references to it to the gnc_register_option functions.
Not tested yet with SWIG, might not work.
Includes introducing fixtures to gtest-gnc-optiondb.cpp.
Provides a type and a raw pointer member with accessors. The type is one of
enum GncOptionIUType and is either VOID (for internal options that don't
get UI items) or one of the widget types specified in dialog-option.c or
business-options-gnome.c.
The objective of the free functions is to hide the GncOption from language
bindings so that the GncOptions can be moved into the GncOptionDB instead
of having shared ptrs splattered around the heap. Nearly all access to
the options can then be mediated through the GncOptionDB container.
Note that gnc_option_db_new creates the GncOptionDB on the heap and
returns a raw ptr, so it's up to the creator of the GncOptionDB to
call delete on it when it's no longer needed.
With the explicit prototypes not marked as static unit test builds on Debian
Buster (using buster-backports) fail with
error: testing::internal::ParamGenerator<TestCase*> gtest_InstantiationAutoClearTestAutoClearTest_EvalGenerator_() was declared extern and later static [-fpermissive]
According to the comment preceding the declaration the only intent of the
explicit prototype (in newer versions of googletest implicitly defined by the
GTEST macros) seems to be to silence a warning which would cause a build
failure on Ubuntu 18.04 when using -Werror.
Builds on Debian unstable seem to build just fine without this explicit
declaration, hence I consider it safe to just drop it. However, builds on
Ubuntu 18.04 then fail (see above).
Making the prototypes as static should make both build environments happy.
app-utils now is an ordinery shared library
A few bits worth mentioning:
1. it's not guile-free just yet, so instead of a gnc_module_load
your code may have to call scm_c_use_module("gnucash app-utils");
to expose the scm side of the app-utils api. This call has been
added to gnucash-bin.c for example
2. while lots of noise in this commit is to rename from gncmodule-app-utils
to gnc-app-utils, I'll point out the library has also been moved from
<libdir>/gnucash to <libdir>. This required changes in app-util's
CMakeLists.txt file for the install side and in the top level
CMakeLists.txt file for the build directory structure.
3. The C side link module test has been removed as linking an ordinary
shared library should be considered well tested by the compiler devs.
The scheme side module load test has been slightly tweaked to no longer
try to use gnc:module-load, but instead now checks whether the app-utils
api is properly exposed to scheme after loading it via use-modules.
4. Dropped a completely obsolete README file.
With that in place we no longer need to (gnc:module-load "gnucash/app-utils" 0)
the app-utils gncmodule. An ordinary (use-modules (gnucash app-utils)) suffices
1. Instead of creating a C wrapper around gettext to then wrap in
guile, use guile's builtin gettext support directly.
The code still defines the _ and N_ shorthands. However it doesn't
really warant a separate module just for these two shorthands.
Instead define them in core-utils. So all code wanting to use
_ or N_ in guile should now use the (gnucash core-utils) module.
The bulk of this commit is actually deleting the scm-gettext
target and using (gnucash core-utils) instead of (gnucash gettext).
2. As the definition of _ and N_ is removed from app-utils.scm,
the app-utils test for a functional N_ macro has been moved to a
new test file in the guile bindinds tests.
3. The (gnucash gettext) module has been deprecated. Use
(gnucash core-utils) from now on.
This commit tries to do the minimum necessary to move the guile bits from engine
to bindings/guile. As engine is a very central piece in the software, this unfortunately
still touches many other source files:
- A few helper objects have been squashed together:
* engine-helpers-guile.[ch] (of which the c part is extracted from engine-helpers.c)
* gncBusGuile.[ch]
* gnc-hooks-scm.[ch]
- The initialization function of gncmod-engine no longer initializes the scm bits.
Any scm code that wants to interact with the engine code now has to load
the (gnucash engine) scm module, or sometimes (gnucash business-core).
The bulk of changes in this commit actually is updating all the scm consumers to do so.
- scm-scm target has been removed. Instead (gnucash utilities) is part
of scm-engine. A few dependency graphs have been updated for this.
More refinements will be in followup commits.
This reverts commit 1a9fcfefad because
on MinGW cmake complains about the paths in pkgconfig files. This can
be addressed by using the MSYS2 cmake instead of the MINGW32 one, but
that requires some other changes... and there's also a path separator
bug in that version of FindPkgConfig.cmake.
These files were installed fairly ad-hoc into the share/gnucash/scm directory making
it hard to get an idea of where each file comes from.
The files are now structured as follows:
- any scm file authored by gnucash should go in share/gnucash/scm/gnucash or below
- most scm modules will be directly in that directory
- each module that comes with support files will get a subdirectory named after the
module's base name. For example next to engine.scm there will be directory
named engine for all support files of the engine module
- scm files that are not modules, but are loaded by modules go into
<module-dir>. For example gnc-utils.scm loads gnc-menu-extensions.scm
so that file will be installed in gnc-utils/gnc-menu-extensions.scm
- the report system is our largest module and only part of the restructuring
is done at this point. It will be refined further in future commits.
The same restructuring is also done for the compiled files.
There are more, but these are most common ones.
There are also a number of urls that don't behave well when https, so those are skipped
At some point I have also started marking non-working URLs as [DEAD LINK], though
that's not a full coverage.
John Ralls
Geert Janssens
Micha Lenk
Christopher Lam
Cristian Klein