Note core-utils.i is used by both the guile and the python bindings so
it is moved up to the common bindings directory, while guile
specific changes are in bindings/guile.
This is done with minimal interpretation, to be able to easily
compare with the original scheme code.
It will most likely be optimized in future commits
When an account is selected for matching the incoming source, at the
moment any account can be selected apart from a place holder account.
If the required commodity is passed in, display a warning if the
selected account is a different commodity and disable the OK button.
On first load the Description and Memo columns are set to the width of
the longest piece of text which can force the Info column out of site
so add the 'ellipsize end' to the memo column which will help keep the
info column in view.
The Info column has a cell_render_pixbuf and a cell_render_text aligned
to the left. If the info column is made larger, the text does not keep
to the left so split them into there own columns.
When change a row to skipping it, a pixbuf is created with just a
vertical black line and looks odd. There is no reason to create a
pixbuf so change the value in the store to NULL. Do the same when
the 'match missing' is displayed.
Previous would call gnc:account-get-balances-at-dates and
gnc:account-accumulate-at-dates to retrieve balances and
last-split. This commit reduces the O(2*N) operation to O(N) which
becomes significant with accounts with large number of splits.
Maybe we can reduce other account splitlist scans in the future; these
will be easier and would only require augmenting the record.
Some invalid txns with splits in the wrong APAR account can be
processed, creating cases whereby split->owner returns an invalid
freshly-allocated owner.
queries xaccSplitGetNoclosingBalance (which is a pointer dereference)
instead of a more complex conditional-based snippet for split->amount,
should be faster.
The category-barchart change will choose the appropriate split->elt
function according to the account type. This is more efficient than
the old split->amount function which includes a conditional.
Note we don't need to test for account being income/expense:
asset/liability accounts do not have Closing transactions. Therefore
we can use xaccSplitGetNoclosingBalance for splits from any account
type.
if acc has no splits before report-date, the nosplit->elt will specify
the default value to be inserted in the result list.
e.g. consider:
dates are (date1 date2 date3 date4 date5)
account has splits starting after date2:
(gnc:account-accumulate-at-dates account dates
#:split->elt (const 'yea) #:nosplit->elt 'nay)
results in '(nay nay yea yea yea)
previously the payment-amount deduction loop used the
payment-split-list to obtain the invoice-posting-split's amount. this
would occasionally fail and would return the invoice-payment-split
amount, obtaining the wrong sign.
modify to retrieve the invoice total via gncInvoice API.
therefore payment-amount, minus gncInvoiceGetTotal(inv) amounts,
results in the overpayment amount.
previous code was very inefficient: if an account had N old splits and
balance-sheet reported on M recent dates, it would scan splitlist
multiple times: (1) to retrieve splits, (2) filter until
column-date, (3) find the last one. i.e. total O(N * M * 3).
this algorithm pre-generates the account's report-date splits by
scanning each account only once, creating M splits which are queried
by get-cell-anchor-fn via list-ref. i.e. O(N)
it is immedialtely converted to a vector because we want O(1)
access. from get-cell-anchor-fn
a future optimisation may scan the accounts' splitlists once per
report run, acquiring all required data (i.e. last period split,
split->balance, closing entries) in 1 pass, to generate a column-data
record.
this is a generalised form from gnc:account-get-balances-at-dates to
accumulate a list from report dates.
this function will scan through account splitlist, processing each
split via split->elt, accumulating results at date boundaries into the
results list. it uses ice-9 match for conciseness.
in: acc - account
dates - a list of time64
split->elt - an unary lambda. the result of calling (split->elt split)
will be accumulated onto the resulting list. by
default it returns the last split-balance before
date boundary, similar to gnc:account-get-balances-at-dates
out: (list elt0 elt1 ...), each entry is the result of split->elt
because:
* list? is O(N), because it needs to test for an improper
list. improper lists are lists whose last pair's cdr cell is not
'(). null? and pair? are both O(1).
* avoids reverse which is also O(N): guile has unlimited stack
therefore we can do non-tail-call loop first to pass as parameter to
the tail-call loop. this removes the need for prepend-and-reverse.
There was error in the trace file for GncPopupEntry of the format...
Object class GncPopupEntry doesn't implement property 'editing-canceled'
from interface 'GtkCellEditable' so added one.
If you list accounts with the "find accounts" dialogue, then delete an
account it has found (e.g. jump & delete), then return to the dialogue,
the dialogue doesn't refresh when the window regains the focus, so you
can accidentally jump to an account you have recently deleted which
will lock up Gnucash.
Fix this by listening to account events and then refresh the list.
