In the budget view there is no option to add the account code column
which some uses use for sorting their accounts. This commit introduces
a feature flag to be used in version 4.0 but if set in 3.8 will hide
the new account code column so the view is not disrupted.
Connect to the 'row-changed' signal for the account tree and do a
redraw on the totals tree view. Also fixes when changing the preference
for using negative amounts in red.
For 1 payment to >1 invoices, previous would miscalculate overpayment.
Old overpayment definition -- from the payment amount, successively
subtract the invoice totals. If remaining is >0, then this is
overpayment. But this fails whereby invoice was partially paid
elsewhere because the overpayment would miss them.
New overpayment definition -- the payment txn is analysed, and all
APAR-splits' lots are analysed. Any lot with no invoice is a
prepayment.
This is a simpler algorithm and does not require the creation and
searching of invoices-and-splits.
For 1 payment to >1 invoices, previous would miscalculate overpayment.
Old overpayment definition -- from the payment amount, successively
subtract the invoice totals. If remaining is >0, then this is
overpayment. But this fails whereby invoice was partially paid
elsewhere because the overpayment would miss them.
New overpayment definition -- the payment txn is analysed, and all
APAR-splits' lots are analysed. Any lot with no invoice is a
prepayment.
Overpayments create at least 2 APAR splits (1 for each invoice, and 1
for the overpayment), they were processed multiple times.
Modify query to return unique transactions, thereby ensuring a payment
gets processed once only.
c21bb66d6 had a regression: income-expense-balances was originally
negated, only to be negated again for use in retained-earnings-fn. The
previous change forgot to negate income-expense-balances.
This commit removes the negation before use of income-expense-balances
in retained-earnings-fn, thereby simplifying code.
because gdk_rgba_to_string() returns a newly-allocated string
* get_negative_color is gchar* instead of const gchar*
* move to dialog-utils.c
* rename get_negative_color() to get_negative_color_str() in
window-main-summarybar.c
* add g_free to gnc_tree_model_account_dispose ()
* modify code to g_free () after use
Emit appropriate deprecation warnings in case code tries to invoke the removed functions.
Only for gnc:module-load a more elaborate compat function has
been written which should allow code using this obsolete function
to continue to function. The emitted deprecation warning will
guide the user to update his/her code for future compatibility.
This is now an ordinary shared library
* Remove test to load the gnc-module in scheme
* Rewrite test to load the module in C to actually test something.
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.
It already ensured it would initialize on first use.
It can as well register the hooks it needs for its
cleanup directly itself instead of depending on the
module loading system to do so.
It's primary purpose is to track gui objects' lifetimes. There's no
need for libgnucash (a non-gui library) to deal with that.
This required two book options related gui-only call backs
to be moved to gnome-utils as well.
With that in place we no longer need to (gnc:module-load "gnucash/html" 0)
the html gncmodule. An ordinary (use-modules (gnucash html)) suffices
html.scm is newly created. It serves two purposes:
1. expose the swigified html api to scheme
2. ensure gnc_html_initialize is run before first use (in scheme) of the api
With that in place we no longer need to (gnc:module-load "gnucash/report" 0)
the report gncmodule. An ordinary (use-modules (gnucash report)) suffices
Note: as gncmod-report did additional initialization, most reports
needed additional tweaks like using app-utils.
And in app-utils the initialization of the relative date terms
has been tweaked as well to run whenever the app-utils module
gets loaded first time, rather than having this initialized by
gncmod-report.
With that in place we no longer need to (gnc:module-load "gnucash/gnome-utils" 0)
the gnome-utils gncmodule. An ordinary (use-modules (gnucash gnome-utils)) suffices
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
The test passed but for the wrong reasons:
as no GNC_MODULE_PATH was passed to the test
it just didn't find the module. That's different
from finding a module with the same name but
a wrong sysver. This commit fixes that.
- move test modules into a subdirectory on Windows as well
- move the futuremod module into its own subdirectory
to avoid its load warnings each time gnc_module_init is called
That also tends to happen when building guile modules.
- remove the log handlers filtering out the futuremodsys warnings
They didn't match the actual warning signature anyway and
they're no longer emitted during testing
This is a first rudimentary separation of gnc-module tests
based on whether they require guile or not. Needs plenty of refinement
which will be applied in followup commits.
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.
