mirror of
https://github.com/Gnucash/gnucash.git
synced 2025-02-25 18:55:30 -06:00
Merge branch 'maint'
This commit is contained in:
commit
695065a0aa
@ -61,7 +61,7 @@ OPTION (ENABLE_BINRELOC "compile with binary relocation support" ON)
|
||||
OPTION (ENABLE_DEBUG "compile with debugging flags set" OFF)
|
||||
OPTION (ENABLE_REGISTER2 "compile with register2 enabled" OFF)
|
||||
OPTION (DISABLE_NLS "do not use Native Language Support" OFF)
|
||||
OPTION (DISABLE_DEPRECATED_GLIB "don't use deprecated glib funcions" OFF)
|
||||
OPTION (DISABLE_DEPRECATED_GLIB "don't use deprecated glib functions" OFF)
|
||||
OPTION (DISABLE_DEPRECATED_GTK "don't use deprectacted gtk, gdk or gdk-pixbuf functions" OFF)
|
||||
OPTION (DISABLE_DEPRECATED_GNOME "don't use deprecated gnome functions" OFF)
|
||||
OPTION (GNC_BUILD_AS_INSTALL "Make build directory structure mirror install" ON)
|
||||
|
1
README
1
README
@ -212,6 +212,7 @@ Building & Installing
|
||||
GnuCash uses GNU Automake to handle the build process, so for most of
|
||||
the details, see the generic instructions in INSTALL. (If you are
|
||||
building directly from Git, read the README.git file for more instructions.)
|
||||
>>>>>>> maint
|
||||
Below we detail the GnuCash specific bits.
|
||||
|
||||
Prior to building GnuCash, you will have to obtain and install the
|
||||
|
25
configure.ac
25
configure.ac
@ -118,7 +118,7 @@ AC_PROG_INSTALL
|
||||
PKG_PROG_PKG_CONFIG
|
||||
|
||||
dnl clang wants to check file encodings, and we need to tell it not to
|
||||
dnl becuase of the unicode currency symbols. But older versions of GCC
|
||||
dnl because of the unicode currency symbols. But older versions of GCC
|
||||
dnl don't like the warning suppression option, so we need to set it only
|
||||
dnl with clang.
|
||||
|
||||
@ -596,7 +596,7 @@ the libtool(-ltdl) development package?])])
|
||||
# version 2.0.10 of SWIG, because that's the first version that supports
|
||||
# guile 2.
|
||||
#
|
||||
# For a guile 1.8 build we accept an older version, but wont allow you
|
||||
# For a guile 1.8 build we accept an older version, but won't allow you
|
||||
# to build the dist because we need to apply a patch to the swig
|
||||
# generated files that needs to go into the release tarball. At that
|
||||
# point we don't know yet which version of guile will be used together
|
||||
@ -718,7 +718,7 @@ then
|
||||
[[GNC_DBD_DIR="$with_dbi_dbd_dir"
|
||||
EXTRA_SEARCH_LIBS=$GNC_DBD_DIR]],
|
||||
[[GNC_DBD_DIR=""
|
||||
# pkg-config is new in libdbi 0.9. Use it if avaiable
|
||||
# pkg-config is new in libdbi 0.9. Use it if available
|
||||
# Otherwise fall back to our previous hard coded values
|
||||
pkg-config --exists dbi
|
||||
if test $? -eq 0; then
|
||||
@ -818,6 +818,7 @@ AC_SUBST(GNC_LIBEXECDIR)
|
||||
AC_ARG_ENABLE( debug,
|
||||
[AS_HELP_STRING([--enable-debug],[compile with debugging flags set])],
|
||||
[
|
||||
if test x$enableval = xyes; then
|
||||
# remove any optimization flags...
|
||||
CFLAGS=`echo ${CFLAGS} | sed -e 's,-O.,,g'`
|
||||
# ...except for those the user wants.
|
||||
@ -826,16 +827,16 @@ AC_ARG_ENABLE( debug,
|
||||
CXXFLAGS=`echo ${CXXFLAGS} | sed -e 's,-O.,,g'`
|
||||
CXXFLAGS="${CXXFLAGS} -g ${USER_OPTIMIZATION}"
|
||||
LDFLAGS="${LDFLAGS} -g"
|
||||
AC_DEFINE(DEBUG_MEMORY,1,[Enable debug memory])
|
||||
],
|
||||
[ AC_DEFINE(DEBUG_MEMORY,0,[Enable debug memory])
|
||||
fi
|
||||
])
|
||||
|
||||
AC_ARG_ENABLE( profile,
|
||||
[AS_HELP_STRING([--enable-profile],[compile with profiling set])],
|
||||
AM_CFLAGS="${AM_CFLAGS} -pg"
|
||||
AM_CXXFLAGS="${AM_CXXFLAGS} -pg"
|
||||
AM_LDFLAGS="${AM_LDFLAGS} -pg")
|
||||
if test x$enableval = xyes; then
|
||||
AM_CFLAGS="${AM_CFLAGS} -pg"
|
||||
AM_CXXFLAGS="${AM_CXXFLAGS} -pg"
|
||||
AM_LDFLAGS="${AM_LDFLAGS} -pg"
|
||||
fi)
|
||||
|
||||
###---------------------------------------------------------------------------
|
||||
### Google Profiler Support: https://code.google.com/p/gperftools/
|
||||
@ -1181,7 +1182,11 @@ LANGINFO_D_FMT_CHECK
|
||||
dnl Enable locale-specific tax-related information in the accounts
|
||||
AC_ARG_ENABLE( locale-specific-tax,
|
||||
[AS_HELP_STRING([--enable-locale-specific-tax],[enable localized tax categories (experimental, but used by the german SKR04 account chart)])],
|
||||
AC_DEFINE(LOCALE_SPECIFIC_TAX,1,Enable the experimental locale-specific tax categories) )
|
||||
[
|
||||
if test x$enableval = xyes; then
|
||||
AC_DEFINE(LOCALE_SPECIFIC_TAX,1,Enable the experimental locale-specific tax categories)
|
||||
fi
|
||||
])
|
||||
|
||||
dnl Make sure we have a proper gettext installed
|
||||
AC_MSG_CHECKING(for a valid gettext/gmsgfmt installation)
|
||||
|
@ -629,7 +629,7 @@ def exec_fillGnuCashDB():
|
||||
crout = 'exec_fillGnuCashDB'
|
||||
filepaths = read_filepaths()
|
||||
if not filepaths:
|
||||
MessageBox('Reading filepaths not successfull.\n' +
|
||||
MessageBox('Reading filepaths not successful.\n' +
|
||||
'Please run makro ' + '"' + set_makro + '"', MsgType="errorbox")
|
||||
return False
|
||||
|
||||
|
@ -24,7 +24,7 @@ HBCI (Home Banking Computer Interface) is a standard used by German
|
||||
banks for offering online banking service. Through this standard,
|
||||
business actions like statement retrieval, initiate bank transfer, or
|
||||
direct debits can be invoked by any HBCI-compliant client application,
|
||||
i.e. now also from GnuCash. Authentification and encryption is done
|
||||
i.e. now also from GnuCash. Authentication and encryption is done
|
||||
through a bank-issued chip card or a self-generated file-based RSA key
|
||||
pair. (In the latter case, the user prints out his public key finger
|
||||
print on paper, signs it, and sends it to his bank.)
|
||||
|
@ -15,7 +15,7 @@ README.OFX
|
||||
|
||||
Since the first 1.7.x beta releases, GnuCash features OFX online banking
|
||||
support. This makes it the world's first *free* OFX-enabled personal
|
||||
finance manager. The developement of OFX and HBCI support also spawned the
|
||||
finance manager. The development of OFX and HBCI support also spawned the
|
||||
a new generic import infrastructure, including a much improved transaction
|
||||
matcher.
|
||||
OFX (Open Financial eXchange) is an open standard increasingly popular
|
||||
@ -199,13 +199,13 @@ output of the ofxdump utility on your file.
|
||||
This is probably bug http://bugzilla.gnome.org/show_bug.cgi?id=101738
|
||||
Unfortunately the main developpers are unable to reproduce. So far, this bug
|
||||
only occurs with OpenSP 1.5. It does not occur for anyone with OpenSP 1.3.x,
|
||||
which is shipped on most Linux distro as part of openjade, so you may wan't to
|
||||
which is shipped on most Linux distro as part of openjade, so you may want to
|
||||
downgrade. (Please note that OpenSP 1.3.x has several other issues however)
|
||||
|
||||
This bug is beleived to be a threading issue, and may be a problem in GnuCash,
|
||||
LibOFX, OpenSP, or some versions of the Linux kernel. If you have any usefull
|
||||
LibOFX, OpenSP, or some versions of the Linux kernel. If you have any useful
|
||||
info,please add a comment to the bug above (even if only to say you encountered
|
||||
the bug,and your version of the previously mentionned packages).
|
||||
the bug,and your version of the previously mentioned packages).
|
||||
|
||||
|
||||
(2) Why doesn't GnuCash support direct connections to bank like Quicken/Money
|
||||
@ -257,7 +257,7 @@ bock@step.polymtl.ca
|
||||
(7) Where do I find/How do I download OFX files for bank XYZ?
|
||||
|
||||
Somewhere on one of the banks website. We can't say anymore than this, the
|
||||
adress, interface, and origin of the info used as user id and password changes
|
||||
address, interface, and origin of the info used as user id and password changes
|
||||
from bank to bank.
|
||||
|
||||
(8) Can I export my Gnucash data in QIF, OFX, CSV, etc. ?
|
||||
|
@ -2,7 +2,7 @@ HOWTO: Translating GnuCash
|
||||
Last update: 2003-07-04
|
||||
|
||||
The concept of this document is to give you step-by-step instructions on
|
||||
how to update (or create if non-existant) language translations for the
|
||||
how to update (or create if non-existent) language translations for the
|
||||
gnucash project.
|
||||
|
||||
Any additions or corrections to this file should be sent to either Jon
|
||||
@ -206,7 +206,7 @@ msgid ""
|
||||
"The GNU way to manage your money!"
|
||||
msgstr ""
|
||||
|
||||
After, the tranlation in the de.po file:
|
||||
After, the translation in the de.po file:
|
||||
|
||||
#: messages-i18n.c:11
|
||||
msgid ""
|
||||
@ -331,7 +331,7 @@ gnc-mdi-utils.c:574"? Open that source file and find line 574:
|
||||
574: gtk_signal_handler_block_by_data(GTK_OBJECT(widget), info);
|
||||
|
||||
So, the problem is with the translation of "_View/_Toolbar". The "/" is a
|
||||
menu seperator, so you now know that the problem is with either the
|
||||
menu separator, so you now know that the problem is with either the
|
||||
translation of "_View" or "_Toolbar". By switching to an English gnucash
|
||||
and looking through your .po file, you should be able to find the problem.
|
||||
Change the offending translation to whatever you see in the gnucash app.
|
||||
@ -377,7 +377,7 @@ For each file:
|
||||
4) Change the gnc-act:title, gnc-act:short-description, and
|
||||
gnc-act:long-description to contain appropriately translated text.
|
||||
Do not add any newlines in the long description except at the end
|
||||
and begining of the string.
|
||||
and beginning of the string.
|
||||
5) For each gnc:account in the file translate the act:name, and
|
||||
act:description fields. Please do not translate any other fields.
|
||||
|
||||
|
@ -35,7 +35,7 @@ as of the date of this split.
|
||||
-- Are these questions supposed to be answered by company A,
|
||||
or do I just 'guess'?
|
||||
|
||||
Note there is still an invarient:
|
||||
Note there is still an invariant:
|
||||
(old price of A) * 20s == (new price of A) *20s + (price of B) * 1s
|
||||
|
||||
\section Depreciation, Sinking Funds ...
|
||||
|
@ -223,7 +223,7 @@
|
||||
of one-another, and to be used in other, non-gnucash projects.
|
||||
For the user, a good extensibility allows the use of
|
||||
<a href="#arrangements">arrangements</a>: a way of broadly
|
||||
customizing the appearence and behaviour of gnucash, and then
|
||||
customizing the appearance and behaviour of gnucash, and then
|
||||
allowing users to very easily share these customizations with
|
||||
one another. Such arrangements might be collections of canned
|
||||
reports, e.g. for business or home user. Or they might be
|
||||
@ -252,7 +252,7 @@
|
||||
People shop on-line. They pay bills on-line. There are
|
||||
even some promising e-wallet systems (such as
|
||||
<a href="http://www.webfunds.org">WebFunds</a>). For GnuCash
|
||||
to be relevent in this on-line world, it must be able to interact
|
||||
to be relevant in this on-line world, it must be able to interact
|
||||
with these systems. There are several steps that can be taken
|
||||
along this path. First, it must be possible to simply and
|
||||
transparently import financial data off the web. Click on a QIF
|
||||
@ -289,7 +289,7 @@
|
||||
sophisticated would also be large and slow to download:
|
||||
it offers no inherent advantages over native code. Another
|
||||
problem with Java is the inherent propreitary fragmentation:
|
||||
no two Java applets are alike: every site has thier own; there
|
||||
no two Java applets are alike: every site has their own; there
|
||||
is no standardization.
|
||||
</p>
|
||||
<p>
|
||||
@ -298,7 +298,7 @@
|
||||
provide "financial aggregation". You sign up with these sites,
|
||||
and let them get all of your credit-card, bank and investment info,
|
||||
and they can provide a unified interface for your bank statements,
|
||||
with graphs and reports (all for a monthly fee). The existance of
|
||||
with graphs and reports (all for a monthly fee). The existence of
|
||||
these services highlights a problem: the inability to aggregate
|
||||
the same data on the users desktop, in a simple, coherent fashion.
|
||||
Let us posit that GnuCash, with the right on-line interfaces,
|
||||
@ -359,7 +359,7 @@
|
||||
|
||||
<dt><b>Bill Presentment, Bill Pay</b></dt>
|
||||
<dd>These magic keywords just mean that a merchant wants to
|
||||
send you a bill, and wants you to go to thier website to
|
||||
send you a bill, and wants you to go to their website to
|
||||
pay that bill (they want your eyeballs). Of course, for
|
||||
the user, it would be more convenient to have the bill
|
||||
show up on the desktop, inside of gnucash, and get authenticated
|
||||
@ -1255,7 +1255,7 @@
|
||||
'backward/forward' buttons to navigate through
|
||||
different registers (the way that a browser navigates
|
||||
web pages.) This of course would be a user
|
||||
preference. Possiblity for doing this exists with MDI.
|
||||
preference. Possibility for doing this exists with MDI.
|
||||
Maybe we shouldn't bother doing this ?? </p>
|
||||
</li>
|
||||
|
||||
@ -1619,13 +1619,13 @@
|
||||
</ul>
|
||||
A good arrangement infrastructure will not only allow gnucash to be configured
|
||||
for different application domains, but also will allow users to fine-tune
|
||||
thier own prefered arrangement. It can also simplify the code base:
|
||||
their own preferred arrangement. It can also simplify the code base:
|
||||
instead of having two products, a home-user application, and a small-business
|
||||
application, each with a different code base and #defines and what not, instead,
|
||||
we have one code base, and different arrangments for each.
|
||||
However, most importantly, the arrangments should be easy to share between users.
|
||||
They should be such that users are encouraged to trade and use arrangments,
|
||||
and to create new ones that suit thier needs.
|
||||
and to create new ones that suit their needs.
|
||||
</p>
|
||||
<p>
|
||||
The idea for arrangements was inspired by
|
||||
@ -2661,7 +2661,7 @@ Password:
|
||||
<p>
|
||||
<b>Status:</b>
|
||||
Done, more or less, gnucash version 1.6.0, Linas Vepstas.
|
||||
Theres still a laundry list of things that need to be
|
||||
There's still a laundry list of things that need to be
|
||||
cleaned up, see the README file in src/engine/sql/README.
|
||||
|
||||
</p>
|
||||
@ -2708,7 +2708,7 @@ Password:
|
||||
|
||||
<dd>
|
||||
Provide support for client/vendor/customer address books,
|
||||
including street addres, eamil, phone. Also: to-do lists,
|
||||
including street address, eamil, phone. Also: to-do lists,
|
||||
a mini-contact manager (when is last time this person
|
||||
was paid? what did they say on phone the last time we
|
||||
sent them a check? Is there a dispute?)
|
||||
@ -2737,7 +2737,7 @@ Password:
|
||||
<li>Somehow, automatically match invoices to payments.
|
||||
When an invoice has been paid off, then there should be a
|
||||
view mode where the invoice and its payment is no longer shown
|
||||
(i.e. so that only outstanding, unpaid entires are shown ...)
|
||||
(i.e. so that only outstanding, unpaid entries are shown ...)
|
||||
<li>create report showing everything but the a/p:
|
||||
Here's an example. I buy a chair for a friend, and three
|
||||
days later he pays me back. What I've been doing is ...
|
||||
|
@ -45,7 +45,7 @@ the subaccount (e.g. A:C for Assets:Cash.)")
|
||||
|
||||
N_( "Want to see all your subaccount transactions in one register? \
|
||||
From the Accounts tab in the main window, highlight the parent account \
|
||||
and select View -> Open Subaccounts from the menu.")
|
||||
and select Edit -> Open Subaccounts from the menu.")
|
||||
|
||||
N_( "When entering dates, you can type '+' or '-' to increment or \
|
||||
decrement the selected date. You can use '+' and '-' to increment and \
|
||||
|
@ -92,7 +92,7 @@
|
||||
"financial calculator: interest rate" "-"
|
||||
"financial calculator: payments" "see: payment"
|
||||
"gain" "An increase in wealth; profit; advantage (See also: capital gains)"
|
||||
"imbalance" "Name of an automaticly created account to get imbalanced transactions back in balance"
|
||||
"imbalance" "Name of an automatically created account to get imbalanced transactions back in balance"
|
||||
"import" "Process of extracting data from a non-Gnucash format into a Gnucash file. E.g. QIF Import."
|
||||
"income statement" "Report that ... FIXME: add description. This report used to be called the 'Profit & Loss', but it was renamed on 2004-07-13."
|
||||
"interest" "Money charged for borrowing money, or paid to somebody who invests money"
|
||||
@ -166,7 +166,7 @@
|
||||
"split" "One of the two or several parts a transaction is divided into"
|
||||
"style sheet" "This sets the particular design or shape of a report."
|
||||
"subtotal" "The total of a set of figures that are part of a larger group of figures"
|
||||
"tax code" "On the goverment's tax forms, the tax code identifies the given line or place on the form where certain amounts must be specified according to the current country's legislation"
|
||||
"tax code" "On the government's tax forms, the tax code identifies the given line or place on the form where certain amounts must be specified according to the current country's legislation"
|
||||
"tax info" "field of an account"
|
||||
"template" "if you create a new e.g. style sheet, you can start from a template"
|
||||
"time period" "see: date range"
|
||||
|
@ -38,10 +38,6 @@ IF (NOT DISABLE_NLS)
|
||||
SET(ENABLE_NLS 1)
|
||||
ENDIF(NOT DISABLE_NLS)
|
||||
|
||||
IF (ENABLE_DEBUG)
|
||||
SET(DEBUG_MEMORY 1)
|
||||
ENDIF(ENABLE_DEBUG)
|
||||
|
||||
IF (ENABLE_BINRELOC)
|
||||
IF (UNIX OR MINGW)
|
||||
SET(BR_PTHREAD 1)
|
||||
|
@ -17,7 +17,7 @@ far.
|
||||
|
||||
gnc-module The module system (actually not a module itself)
|
||||
|
||||
calculation Low-level expresion parsing & financial
|
||||
calculation Low-level expression parsing & financial
|
||||
equation solving.
|
||||
|
||||
engine The engine module, without any backends
|
||||
|
@ -218,7 +218,7 @@
|
||||
*
|
||||
* are recognized. All numerics are initially recognized as positive
|
||||
* numbers. If negative, the unary '-' operator is applied. This saves
|
||||
* the logic of having to recogize strings as
|
||||
* the logic of having to recognize strings as
|
||||
*
|
||||
* -123
|
||||
*
|
||||
@ -272,7 +272,7 @@
|
||||
*
|
||||
* There are six parser functions needed to use the parser/evaluator:
|
||||
*
|
||||
* Note: in the last five functions, in the function paramter (void
|
||||
* Note: in the last five functions, in the function parameter (void
|
||||
* *vp), "vp" is the pointer returned by the "init_parser" function.
|
||||
*
|
||||
* void *init_parser(var_store_ptr predefined_vars,
|
||||
@ -304,7 +304,7 @@
|
||||
* in subsequent calls to the parser. -- the third parameter
|
||||
* is the optional character used for grouping digits to the
|
||||
* left of the radix. -- The fourth, fifth, sixth and seventh
|
||||
* parameters are the functions I descibed above for the
|
||||
* parameters are the functions I described above for the
|
||||
* internal numeric representation desired by the calling
|
||||
* function(s).
|
||||
*
|
||||
@ -579,7 +579,7 @@ delete_var (char *var_name, parser_env_ptr pe)
|
||||
/* parse string passed using parser environment passed return
|
||||
* evaluated value in numeric structure passed, return NULL if no
|
||||
* parse error. If parse error, return pointer to character at which
|
||||
* error occured. */
|
||||
* error occurred. */
|
||||
char *
|
||||
parse_string (var_store_ptr value, const char *string, parser_env_ptr pe)
|
||||
{
|
||||
|
@ -121,7 +121,7 @@
|
||||
* and payment periods, and the term must be expressed as the total number of
|
||||
* payments (or compounding periods if there are no payments). Loans, leases,
|
||||
* mortgages, annuities, savings plans, appreciation, and compound growth are
|
||||
* amoung the many financial problems that can be defined in these terms. Some
|
||||
* among the many financial problems that can be defined in these terms. Some
|
||||
* transactions do not involve payments, but all of the other factors play a
|
||||
* part in "time value of money" transactions. When any one of the five (four
|
||||
* - if no payments are involved) factors is unknown, it can be derived from
|
||||
@ -138,13 +138,13 @@
|
||||
* If payments are a part of the transaction, the number of payments
|
||||
* must * equal the number of periods (n).
|
||||
*
|
||||
* Payments may be represented as occuring at the end or beginning of
|
||||
* Payments may be represented as occurring at the end or beginning of
|
||||
* the * periods.
|
||||
*
|
||||
* Diagram to visualize the positive and negative cash flows (cash
|
||||
* flow * diagrams):
|
||||
*
|
||||
* Amounts shown above the line are positve, received, and amounts
|
||||
* Amounts shown above the line are positive, received, and amounts
|
||||
* shown below the line are negative, paid out.
|
||||
*
|
||||
* 1)
|
||||
@ -555,8 +555,8 @@
|
||||
* Constant payment to principal loan
|
||||
*
|
||||
* In this loan, each total payment is different, with each
|
||||
* succeeding payment less than the preceeding payment. Each payment
|
||||
* is the total of the constant ammount to the principal plus the
|
||||
* succeeding payment less than the preceding payment. Each payment
|
||||
* is the total of the constant amount to the principal plus the
|
||||
* interest for the period. The constant payment to the principal is
|
||||
* computed as:
|
||||
*
|
||||
@ -622,7 +622,7 @@
|
||||
* first payment period for end of period payments.
|
||||
*
|
||||
* This is not always true. IP may be delayed for financial reasons
|
||||
* such as cash flow or accounting calender. The subsequent payments
|
||||
* such as cash flow or accounting calendar. The subsequent payments
|
||||
* then follow the agreed upon periodicity. Since money has a time
|
||||
* value, the "delayed" IP must be accounted for. Computing an
|
||||
* "Effective PV", pve, is one means of handling a delayed IP.
|
||||
@ -758,7 +758,7 @@
|
||||
*
|
||||
* ===========================================================================
|
||||
* NOTE: For Payment Frequencies, PF, semi-monthly or less, i.e., PF
|
||||
* == 12 or PF == 24, a 360 day calender year and 30 day month are
|
||||
* == 12 or PF == 24, a 360 day calendar year and 30 day month are
|
||||
* used. For Payment Frequencies, PF, greater than semi-monthly, PF
|
||||
* > 24, the actual number of days per year and per payment period
|
||||
* are used. The actual values are computed using the built-in
|
||||
@ -766,10 +766,10 @@
|
||||
*
|
||||
* ****************************************************************************
|
||||
*
|
||||
* Note: in the following examples, the user input is preceeded by the
|
||||
* Note: in the following examples, the user input is preceded by the
|
||||
* prompt "<>". The result of evaluating the input expression is then
|
||||
* displayed. I have taken the liberty of including comments in the
|
||||
* example input/output sessions by preceeding with ' *'. Thus, for
|
||||
* example input/output sessions by preceding with ' *'. Thus, for
|
||||
* the line: <>n=5 *set number of periods the comment that setting the
|
||||
* number of periods is not really input and the true input is only:
|
||||
* <>n=5
|
||||
@ -1575,12 +1575,12 @@ set_default (fi_ptr fi)
|
||||
|
||||
} /* set_default */
|
||||
|
||||
/* compute Julian Day Number from calender date
|
||||
/* compute Julian Day Number from calendar date
|
||||
*/
|
||||
unsigned long
|
||||
julian_day_number (unsigned year, unsigned month, unsigned day)
|
||||
{
|
||||
/* Gregorian/Julian Calender Flag.
|
||||
/* Gregorian/Julian Calendar Flag.
|
||||
* TRUE == Julian
|
||||
* FALSE == Gregorian
|
||||
*/
|
||||
|
@ -153,7 +153,7 @@ typedef struct amort_sched_yr
|
||||
amort_sched_yr;
|
||||
|
||||
/* structure used by amortization routines for passing and storing
|
||||
* infomation on a particular amortization transaction */
|
||||
* information on a particular amortization transaction */
|
||||
typedef struct amort_sched *amort_sched_ptr;
|
||||
typedef struct amort_sched
|
||||
{
|
||||
@ -202,7 +202,7 @@ typedef struct amort_sched
|
||||
double delayed_int; /* interest due to delayed initial payment */
|
||||
double fixed_pmt; /* fixed prepayment amount for amortization */
|
||||
unsigned new_n; /* new number of periods to amortize due to
|
||||
delayed intial payment */
|
||||
delayed initial payment */
|
||||
unsigned fv_case; /* fv case flag */
|
||||
unsigned long Eff_Date_jdn;
|
||||
unsigned yday_E;
|
||||
|
@ -36,7 +36,7 @@
|
||||
operate on engine data structures, so they don't belong in
|
||||
src/engine/Period.c. Putting them into src/engine/gnc-date.c
|
||||
would be the best place for them, but then that creates a new
|
||||
dependancy from the src/engine directory to the src/core-utils
|
||||
dependency from the src/engine directory to the src/core-utils
|
||||
directory that doesn't currently exist. Since that might be a
|
||||
problem for CashUtils, the app-file directory was chosen.
|
||||
*/
|
||||
|
@ -36,7 +36,7 @@
|
||||
operate on engine data structures, so they don't belong in
|
||||
src/engine/Period.c. Putting them into src/engine/gnc-date.c
|
||||
would be the best place for them, but then that creates a new
|
||||
dependancy from the src/engine directory to the src/core-utils
|
||||
dependency from the src/engine directory to the src/core-utils
|
||||
directory that doesn't currently exist. Since that might be a
|
||||
problem for CashUtils, the app-file directory was chosen.
|
||||
*/
|
||||
|
@ -234,7 +234,7 @@ void gnc_suspend_gui_refresh (void);
|
||||
* Resume refresh handlers by the component manager.
|
||||
* Each call reduces the suspend counter by one. When
|
||||
* the counter reaches zero, all changes which have
|
||||
* occured since the last refresh are collected and
|
||||
* occurred since the last refresh are collected and
|
||||
* passed to the components in refresh handlers.
|
||||
*/
|
||||
void gnc_resume_gui_refresh (void);
|
||||
|
@ -23,6 +23,7 @@
|
||||
|
||||
#include "gnc-euro.h"
|
||||
|
||||
#include <glib/gi18n.h>
|
||||
#include <math.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
|
@ -43,7 +43,7 @@ void gnc_exp_parser_init (void);
|
||||
/**
|
||||
* The real init function, which takes an option to add the pre-defined vars
|
||||
* to the variable table. This option is used by
|
||||
* gnc_exp_parser_parse_seperate_vars [itself used by the Scheduled
|
||||
* gnc_exp_parser_parse_separate_vars [itself used by the Scheduled
|
||||
* Transaction code] to parse without using any "predefined" application
|
||||
* variables.
|
||||
**/
|
||||
|
@ -28,6 +28,7 @@
|
||||
|
||||
extern "C"
|
||||
{
|
||||
#define _(X) X
|
||||
#include "config.h"
|
||||
|
||||
#include <sys/types.h>
|
||||
|
@ -499,7 +499,7 @@ gnc_account_end_handler (gpointer data_for_children,
|
||||
*/
|
||||
xaccAccountBeginEdit (acc);
|
||||
|
||||
/* Backwards compatability. If there's no parent, see if this
|
||||
/* Backwards compatibility. If there's no parent, see if this
|
||||
* account is of type ROOT. If not, find or create a ROOT
|
||||
* account and make that the parent. */
|
||||
parent = gnc_account_get_parent (acc);
|
||||
|
@ -41,7 +41,7 @@ extern "C"
|
||||
#include "qof.h"
|
||||
|
||||
/* FIXME: eventually, we probably need to add an error stack
|
||||
accessable via gnc_book_get_xml_io_error() a la binfile. */
|
||||
accessible via gnc_book_get_xml_io_error() a la binfile. */
|
||||
|
||||
/** Read in an account group from a file */
|
||||
gboolean qof_session_load_from_xml_file (QofBook*, const char* filename);
|
||||
|
@ -7,9 +7,6 @@
|
||||
/* Include pthread support for binary relocation? */
|
||||
#cmakedefine BR_PTHREAD 1
|
||||
|
||||
/* Enable debug memory */
|
||||
#cmakedefine01 DEBUG_MEMORY
|
||||
|
||||
/* Use binary relocation? */
|
||||
#cmakedefine ENABLE_BINRELOC
|
||||
|
||||
|
@ -58,7 +58,7 @@ SCM gnc_scm_call_1_to_procedure(SCM func, SCM arg);
|
||||
SCM gnc_scm_call_1_to_list(SCM func, SCM arg);
|
||||
SCM gnc_scm_call_1_to_vector(SCM func, SCM arg);
|
||||
|
||||
/* Deprectated functions, will be removed soon */
|
||||
/* Deprecated functions, will be removed soon */
|
||||
#define gnc_guile_call1_to_string gnc_scm_call_1_to_string
|
||||
#define gnc_guile_call1_symbol_to_string gnc_scm_call_1_symbol_to_string
|
||||
#define gnc_guile_call1_to_procedure gnc_scm_call_1_to_procedure
|
||||
|
@ -1,5 +1,5 @@
|
||||
/* This file is part of:
|
||||
* Jalali, a Gregorian to Jalali and inverse date convertor
|
||||
* Jalali, a Gregorian to Jalali and inverse date converter
|
||||
* Copyright (C) 2001 Roozbeh Pournader <roozbeh@sharif.edu>
|
||||
* Copyright (C) 2001 Mohammad Toossi <mohammad@bamdad.org>
|
||||
*
|
||||
|
@ -50,7 +50,7 @@ test_strings strs[] =
|
||||
G_DIR_SEPARATOR_S "tmp" G_DIR_SEPARATOR_S "test-account-name2", 0
|
||||
},
|
||||
/* TODO Figure out how to write tests that actually verify the relative
|
||||
* pathname resolution. The above tests only test absolut pathnames */
|
||||
* pathname resolution. The above tests only test absolute pathnames */
|
||||
{ NULL, NULL, 0 },
|
||||
};
|
||||
|
||||
|
@ -10,10 +10,10 @@ Bob Drzyzgula
|
||||
|
||||
At this point, this document contains my personal thoughts about possible
|
||||
design criteria for a budgeting engine in GnuCash. These should not
|
||||
at this writing be taken as concensus opinion, and may in places be
|
||||
at this writing be taken as consensus opinion, and may in places be
|
||||
at odds with conventions inside GnuCash code (and with general accounting
|
||||
principals... I am in no way an accountant), and thus may not be practical.
|
||||
However, I believe that they provide a self-consistant view of how
|
||||
However, I believe that they provide a self-consistent view of how
|
||||
one might do this, and I hope that this document will serve to continue
|
||||
the discussion that began on the GnuCash/Xacc mailing list.
|
||||
|
||||
@ -97,7 +97,7 @@ here.
|
||||
|
||||
\subsection budgetdocs Documenting the Budget
|
||||
|
||||
One possible way to document a budget might be as a classic ``input-ouput
|
||||
One possible way to document a budget might be as a classic ``input-output
|
||||
table''. Consider the following table:
|
||||
\verbatim
|
||||
+---------+----------+---------+-----+------+------+-----+------+------+
|
||||
@ -195,7 +195,7 @@ Where I'm headed for the rest of it is this:
|
||||
$0.40 on Friday because they have burritos on
|
||||
Friday and she hates them and brings her lunch but
|
||||
still needs milk" into something usable as a
|
||||
budget -or- as a schedule (these being two seperate
|
||||
budget -or- as a schedule (these being two separate
|
||||
outputs).
|
||||
- While I expect that such an engine would be extremely
|
||||
useful for about 80% of the data that would go into
|
||||
|
@ -9,8 +9,8 @@
|
||||
<HR>
|
||||
<h1>Constant Repayment to Principal Equations Derivation</h1>
|
||||
<p>In this loan, each total payment is different, with each succeeding payment
|
||||
less than the preceeding payment. Each payment is the total of the constant
|
||||
ammount to the principal plus the interest for the period. The constant payment
|
||||
less than the preceding payment. Each payment is the total of the constant
|
||||
amount to the principal plus the interest for the period. The constant payment
|
||||
to the principal is computed as:
|
||||
|
||||
<pre>
|
||||
@ -86,7 +86,7 @@ would give the following equations:
|
||||
T[n] = -i*n*PV*(2*N - n + 1)/(2*N)
|
||||
</pre>
|
||||
|
||||
<p>Using thses equations for the calculations would eliminate the dependence
|
||||
<p>Using these equations for the calculations would eliminate the dependence
|
||||
on C, but only if C is always defined as above and would eliminate the
|
||||
possibility of another value for C. If the value of C was less than -PV/N
|
||||
then a balloon payment would be due at the final payment and this is a possible
|
||||
|
@ -40,7 +40,7 @@ Note that some financial constraints are so core, so key to GnuCash
|
||||
that they are woven into the object design itself. For example, the
|
||||
posted date is a part of the transaction: different splits cannot
|
||||
possibly have different posted dates, as there is no mechanism to
|
||||
represent this. All splits get thier posted date from thier parent
|
||||
represent this. All splits get their posted date from their parent
|
||||
transaction.
|
||||
|
||||
The constraints that we are most interested in are the ones that
|
||||
@ -50,7 +50,7 @@ run at specific times and alter the data to be self-consistent in
|
||||
certain ways. The 'double-entry' constraint belongs to this class:
|
||||
it computes the total value of all the splits in a transaction, and
|
||||
adds one, if needed, to bring the total to zero. This constraint
|
||||
runs when the transaction is commited. Although this is an important
|
||||
runs when the transaction is committed. Although this is an important
|
||||
cosntraint, there is no (easy) way to reflect it directly in the
|
||||
object design; thus, it acts as a rule that must be periodically
|
||||
imposed.
|
||||
@ -92,7 +92,7 @@ they are, and how they work.
|
||||
See the document 'lots.txt', section 'Cap Gains Actual Implementation'
|
||||
for details.
|
||||
- Value of Gains Transaction
|
||||
The value recorded by teh gains transaction is kept in sync with
|
||||
The value recorded by the gains transaction is kept in sync with
|
||||
the value
|
||||
|
||||
*/
|
||||
|
@ -328,7 +328,7 @@ every component watching for that event is invoked.
|
||||
@deftypefun void gnc_resume_gui_refresh (void)
|
||||
Resume the invocation of refresh handlers by the Component Manager.
|
||||
Each call reduces the suspend counter by one. When the counter reaches
|
||||
zero, all events which have occured since the last refresh are collected
|
||||
zero, all events which have occurred since the last refresh are collected
|
||||
and passed to refresh handlers via the @var{changes} argument. Refresh
|
||||
handlers will still be excluded based on their watches.
|
||||
@end deftypefun
|
||||
|
@ -145,7 +145,7 @@ disadvantages:
|
||||
@itemize
|
||||
|
||||
@item
|
||||
Pointers cannot be used in data files and are not persistant across
|
||||
Pointers cannot be used in data files and are not persistent across
|
||||
different program invocations.
|
||||
|
||||
@item
|
||||
@ -193,7 +193,7 @@ GUIDs can be efficiently encoded in a string representation.
|
||||
@cindex When to use GUIDs
|
||||
|
||||
Although GUIDs are very flexible, the engine structures like Accounts
|
||||
will probably continue to use C pointers for the forseeable future,
|
||||
will probably continue to use C pointers for the foreseeable future,
|
||||
since they are much faster (and in certain respects more convenient)
|
||||
than using GUIDs. In general, however, it is much safer to use GUIDs.
|
||||
In particular, you should consider using GUIDs if any of the following
|
||||
@ -390,7 +390,7 @@ GnuCash code should use @code{xaccGUIDNew}.
|
||||
@tindex gnc_numeric
|
||||
|
||||
=============== The documentation below for gnc_numeric is obsolete
|
||||
and has been superseeded by the gnc_numeric docs in the header file.
|
||||
and has been superseded by the gnc_numeric docs in the header file.
|
||||
=========================================
|
||||
|
||||
Financial quantities in GnuCash (Split quantities and values) are stored
|
||||
@ -431,7 +431,7 @@ functions have not been implemented for @code{gnc_numeric} objects.
|
||||
@cindex Standard Numeric Arguments
|
||||
|
||||
=============== The documentation below for gnc_numeric is obsolete
|
||||
and has been superseeded by the gnc_numeric docs in the header file.
|
||||
and has been superseded by the gnc_numeric docs in the header file.
|
||||
=========================================
|
||||
|
||||
It is useful to specify a denominator in cases where it is known that
|
||||
@ -564,7 +564,7 @@ GNC_RND_NEVER} as @var{how}.
|
||||
@node Creating Numeric Objects, Basic Arithmetic Operations, Standard Numeric Arguments, Numeric Library
|
||||
|
||||
=============== The documentation below for gnc_numeric is obsolete
|
||||
and has been superseeded by the gnc_numeric docs in the header file.
|
||||
and has been superseded by the gnc_numeric docs in the header file.
|
||||
=========================================
|
||||
|
||||
@subsection Creating Numeric Objects
|
||||
@ -690,7 +690,7 @@ Arguments} and compare numerators of the result.
|
||||
|
||||
@node Numeric Denominator Conversion, Numeric Floating Point Conversion, Numeric Comparisons and Predicates, Numeric Library
|
||||
=============== The documentation below for gnc_numeric is obsolete
|
||||
and has been superseeded by the gnc_numeric docs in the header file.
|
||||
and has been superseded by the gnc_numeric docs in the header file.
|
||||
=========================================
|
||||
|
||||
@subsection Numeric Denominator Conversion
|
||||
@ -783,7 +783,7 @@ noted by @var{error_code} rather than a number.
|
||||
@cindex Numeric Example
|
||||
|
||||
=============== The documentation below for gnc_numeric is obsolete
|
||||
and has been superseeded by the gnc_numeric docs in the header file.
|
||||
and has been superseded by the gnc_numeric docs in the header file.
|
||||
=========================================
|
||||
|
||||
The following program finds the best @code{gnc_numeric} approximation to
|
||||
@ -984,7 +984,7 @@ path does not exist, it is created.
|
||||
Works like @code{kvp_frame_get_frame}, but the frame path is specified
|
||||
as a single string where the keys are separated by slashes; thus, for
|
||||
example: @code{/this/is/a/valid/path} and @code{///so//is////this/}.
|
||||
Multiple slashes are compresed and a leading slash is optional. The
|
||||
Multiple slashes are compressed and a leading slash is optional. The
|
||||
pointers @code{.} and @code{..} are @emph{not} followed/obeyed. (This
|
||||
is arguably a bug that needs fixing).
|
||||
@end deftypefun
|
||||
@ -1925,7 +1925,7 @@ Set the share price of @var{split} to @var{price}.
|
||||
|
||||
@deftypefun void xaccSplitSetSharePriceAndAmount (Split * @var{split}, gnc_numeric @var{price}, gnc_numeric @var{amount})
|
||||
Set both the share price and share quantity of @var{split}. This routine
|
||||
is more efficent than calling @code{xaccSplitSetShareAmount} and
|
||||
is more efficient than calling @code{xaccSplitSetShareAmount} and
|
||||
@code{xaccSplitSetSharePrice} in succesion.
|
||||
@end deftypefun
|
||||
|
||||
@ -2706,7 +2706,7 @@ of what a file system is, or where they want to keep their data files.
|
||||
The current implementation assumes the use of files and file locks;
|
||||
however, the API was designed to be general enough to allow the use
|
||||
of generic URL's, and/or implementation on top of SQL or other
|
||||
database/persistant object technology.
|
||||
database/persistent object technology.
|
||||
|
||||
@menu
|
||||
* GNCBook API::
|
||||
@ -2727,7 +2727,7 @@ memory associated with it.
|
||||
@end deftypefun
|
||||
|
||||
@deftypefun gboolean gnc_book_begin (GNCBook * @var{book}, const char * @var{book_id}, gboolean ignore_lock, gboolean create_if_nonexistent)
|
||||
Begins a new book editing sesssion. It takes as an argument the book id.
|
||||
Begins a new book editing session. It takes as an argument the book id.
|
||||
The book id must be a string in the form of a URI/URL. In the current
|
||||
implementation, only one type of URI is supported, and that is the file
|
||||
URI: anything of the form @url{file:/home/somewhere/somedir/file.xac}
|
||||
|
@ -41,7 +41,7 @@ returns a new, empty options database that you can then add options to.
|
||||
|
||||
Options are organised into sections, which are each given a title string
|
||||
such as "Register" or "International". The UI displays each section on
|
||||
a seperate page. Each section has a number of options. Each option has
|
||||
a separate page. Each section has a number of options. Each option has
|
||||
a name that uniquely identifies it in that section, and an alphabetic
|
||||
@dfn{sort tag} that determines the relative ordering of the options for
|
||||
display.
|
||||
@ -52,7 +52,7 @@ display.
|
||||
Sometimes, GnuCash requires the user to specify true/false properties.
|
||||
Others properties most easily specified by selections from a list,
|
||||
others from a number, others still by selecting dates, or one or more
|
||||
accounts in the account hierachy, or even colors. GnuCash supports all
|
||||
accounts in the account hierarchy, or even colors. GnuCash supports all
|
||||
of these and more:
|
||||
|
||||
@table @code
|
||||
@ -85,7 +85,7 @@ in relative or absolute terms.
|
||||
@item account-list
|
||||
|
||||
For selecting a particular account or accounts. The UI displays a tree
|
||||
of the account hierachy.
|
||||
of the account hierarchy.
|
||||
|
||||
@item multichoice
|
||||
|
||||
|
@ -1714,7 +1714,7 @@ UML_LOOK = NO
|
||||
# the class node. If there are many fields or methods and many nodes the
|
||||
# graph may become too big to be useful. The UML_LIMIT_NUM_FIELDS
|
||||
# threshold limits the number of items for each type to make the size more
|
||||
# managable. Set this to 0 for no limit. Note that the threshold may be
|
||||
# manageable. Set this to 0 for no limit. Note that the threshold may be
|
||||
# exceeded by 50% before the limit is enforced.
|
||||
|
||||
UML_LIMIT_NUM_FIELDS = 10
|
||||
|
@ -22,7 +22,7 @@ pointer chasing between different types of existing C structs,
|
||||
or whether it more naturally can hang with some existing object.
|
||||
|
||||
If it seems to be an independent concept, it can still be placed
|
||||
in the KVP tree of the book, which gives it a 'top-level' existance.
|
||||
in the KVP tree of the book, which gives it a 'top-level' existence.
|
||||
|
||||
If the concept is used only infrequently, then it probably belongs
|
||||
in a KVP tree. If the concept has performance-critical requriements,
|
||||
@ -33,7 +33,7 @@ can be queried efficiently and rapidly.
|
||||
\subsection terms Terminology:
|
||||
|
||||
- First-class object: something that has a C struct associated with it,
|
||||
and has its own specialized backend infrastructure for storing/quering
|
||||
and has its own specialized backend infrastructure for storing/querying
|
||||
it.
|
||||
|
||||
- Second-class object: something that lives entirely in a KVP tree.
|
||||
|
@ -192,7 +192,7 @@ adhered to: the interest rate must be relative to the compounding frequency
|
||||
and payment periods, and the term must be expressed as the total number of
|
||||
payments (or compounding periods if there are no payments). Loans, leases,
|
||||
mortgages, annuities, savings plans, appreciation, and compound growth are
|
||||
amoung the many financial problems that can be defined in these terms. Some
|
||||
among the many financial problems that can be defined in these terms. Some
|
||||
transactions do not involve payments, but all of the other factors play a
|
||||
part in "time value of money" transactions. When any one of the five (four
|
||||
- if no payments are involved) factors is unknown, it can be derived from
|
||||
@ -217,13 +217,13 @@ the line.
|
||||
<p>If payments are a part of the transaction, the number of payments must
|
||||
equal the number of periods (n).
|
||||
|
||||
<p>Payments may be represented as occuring at the end or beginning of the
|
||||
<p>Payments may be represented as occurring at the end or beginning of the
|
||||
periods.
|
||||
|
||||
<p>Diagram to visualize the positive and negative cash flows (cash flow
|
||||
diagrams):
|
||||
|
||||
<p>Amounts shown above the line are positve, received, and amounts shown below the
|
||||
<p>Amounts shown above the line are positive, received, and amounts shown below the
|
||||
line are negative, paid out.
|
||||
|
||||
<hr>
|
||||
@ -435,7 +435,7 @@ IP is equal to ED for beginning of period payments or at the end of the
|
||||
first payment period for end of period payments.
|
||||
|
||||
<p>This is not always true. IP may be delayed for financial reasons such as cash
|
||||
flow or accounting calender. The subsequent payments then follow the
|
||||
flow or accounting calendar. The subsequent payments then follow the
|
||||
agreed upon periodicity.
|
||||
|
||||
<A name="Eff_PV">
|
||||
@ -650,7 +650,7 @@ can afford larger payments.
|
||||
|
||||
<!--================================================================================-->
|
||||
<p>NOTE: For Payment Frequencies, PF, semi-monthly or less, i.e., PF == 12 or PF == 24,
|
||||
a 360 day calender year and 30 day month are used. For Payment Frequencies, PF,
|
||||
a 360 day calendar year and 30 day month are used. For Payment Frequencies, PF,
|
||||
greater than semi-monthly, PF > 24, the actual number of days per year and per payment
|
||||
period are used. The actual values are computed using the built-in 'jdn' function
|
||||
|
||||
@ -949,10 +949,10 @@ saved in the variable, <tt>sofmt</tt>, and later restored.
|
||||
|
||||
<a name="Examples">
|
||||
<h1>Examples</h1></a>
|
||||
<!-- Note: in the following examples, the user input is preceeded by the prompt -->
|
||||
<!-- Note: in the following examples, the user input is preceded by the prompt -->
|
||||
<!-- "<>". The result of evaluating the input expression is then displayed. -->
|
||||
<!-- I have taken the liberty of including comments in the example -->
|
||||
<!-- input/output sessions by preceeding with '#'. Thus, for the line: -->
|
||||
<!-- input/output sessions by preceding with '#'. Thus, for the line: -->
|
||||
<!-- <>n=5 #set number of periods -->
|
||||
<!-- the comment that setting the number of periods is not really input and the true-->
|
||||
<!-- input is only: -->
|
||||
|
@ -33,7 +33,7 @@ One practical problem is that backup copies of files containing
|
||||
GnuCash data will have the same GUID's as the 'live data'. Because
|
||||
the user may have modified the object, if one looked at the backup
|
||||
copy, one would find more-or-less the same object, but it might
|
||||
have different values (for the amount, the value, teh date, the
|
||||
have different values (for the amount, the value, the date, the
|
||||
title, etc.) Thus, a single value for a GUID can be associated
|
||||
with several different but similar 'objects'.
|
||||
|
||||
|
@ -380,10 +380,10 @@ Things not kept in sync:
|
||||
The posted date is kept in sync using a data-constraint scheme.
|
||||
If xaccTransactionSetDatePosted() is called, the date change is
|
||||
accepted, and the split is marked date-dirty. When the transaction
|
||||
is commited (using xaccTransCommitEdit()), the date-dirty flag
|
||||
is committed (using xaccTransCommitEdit()), the date-dirty flag
|
||||
is evaluated, and, if needed, the date changes are propagated/rolled
|
||||
back on the appropriate gains splits. Currently, one can only change
|
||||
the date on the gains-source transaction; the date on teh
|
||||
the date on the gains-source transaction; the date on the
|
||||
gains-recording split cannot be changed.
|
||||
|
||||
The value recorded by the gains transaction is updated whenever
|
||||
@ -397,14 +397,14 @@ dirty flags are used to track these.
|
||||
If the amount of a plit changes, then the lot that its in becomes
|
||||
potentially unbalanced. This requires the lot membership to be
|
||||
recomputed; this in turn may require the split to be split into
|
||||
peices, or to be recombined into one from several pieces.
|
||||
pieces, or to be recombined into one from several pieces.
|
||||
|
||||
\section lotstodo TODO
|
||||
- need to copy void status when source split date changes.
|
||||
- its possible for the the price, as recorded by one split
|
||||
to vary wildly from that in another split in the same
|
||||
transaction. That's bad, prices should be normalized.
|
||||
Theres a routine to do this, xaccScrubSubSplitPrice()
|
||||
There's a routine to do this, xaccScrubSubSplitPrice()
|
||||
but its not currently used.
|
||||
- write automated test cases to handle each situation.
|
||||
|
||||
|
@ -12,7 +12,7 @@
|
||||
<cstim> How are you printing balances right now?
|
||||
I guess you plug a \a gnc-numeric into the html code.
|
||||
If you do a s/\a gnc-numeric/\a gnc-monetary/
|
||||
... then everything would be multi-currency compilant
|
||||
... then everything would be multi-currency compliant
|
||||
Of course the \a gnc-monetary needs the actual currency specified.
|
||||
Would that lead to problems?
|
||||
Definition of \a gnc-monetary is in src/scm/gnc-numeric.scm
|
||||
|
@ -52,7 +52,7 @@
|
||||
#
|
||||
# @subsection swigworks What SWIG does
|
||||
#
|
||||
# SWIG extracts informations from the c-sources and provides access to the structures
|
||||
# SWIG extracts information from the c-sources and provides access to the structures
|
||||
# to python. It's work is controlled by interface files :
|
||||
#
|
||||
# @li gnucash_core.i
|
||||
|
@ -164,7 +164,7 @@ gboolean qif_file_needs_account(QifFile file);
|
||||
void qif_file_set_default_account(QifFile file, const char *acct_name);
|
||||
|
||||
/** Parse the qif file values; may require some callbacks to let the
|
||||
* user choose from ambigious data formats
|
||||
* user choose from ambiguous data formats
|
||||
* XXX: Is there a better way to callback from here?
|
||||
* Do we need progress-bar info here?
|
||||
*/
|
||||
|
@ -784,7 +784,7 @@ gint gnc_account_get_current_depth (const Account *account);
|
||||
|
||||
/** Return the number of levels of descendants accounts below the
|
||||
* specified account. The returned number does not include the
|
||||
* specifed account itself.
|
||||
* specified account itself.
|
||||
*
|
||||
* @param account The account to query.
|
||||
*
|
||||
|
@ -114,7 +114,7 @@ predicate d, you will get (ad + bd + cd).
|
||||
STRUCTURE OF A QUERY: A Query is a logical function of any number of
|
||||
QueryTerms. A QueryTerm consists of a C function pointer (the
|
||||
Predicate) and a PredicateData structure containing data passed to the
|
||||
predicate funtion. The PredicateData structure is a constant
|
||||
predicate function. The PredicateData structure is a constant
|
||||
associated with the Term and is identical for every Split that is
|
||||
tested.
|
||||
|
||||
@ -158,7 +158,7 @@ PD_AMOUNT : match a numeric amount. Specify an amount (always
|
||||
positive), a funds-flow direction (credit, debit, or either), and
|
||||
"how", specifying the type of amount comparison to be used :
|
||||
|
||||
AMT_MATCH_ATLEAST : split >= pd amount
|
||||
AMT_MATCH_AT LEAST : split >= pd amount
|
||||
AMT_MATCH_ATMOST : split >= pd amount
|
||||
AMT_MATCH_EXACTLY : split == pd amount
|
||||
|
||||
|
@ -110,7 +110,7 @@ guint recurrenceGetMultiplier(const Recurrence *r);
|
||||
GDate recurrenceGetDate(const Recurrence *r);
|
||||
WeekendAdjust recurrenceGetWeekendAdjust(const Recurrence *r);
|
||||
|
||||
/* Get the occurence immediately after refDate.
|
||||
/* Get the occurrence immediately after refDate.
|
||||
*
|
||||
* This function has strict and precise post-conditions:
|
||||
*
|
||||
@ -133,7 +133,7 @@ void recurrenceNextInstance(const Recurrence *r, const GDate *refDate,
|
||||
/* Zero-based. n == 1 gets the instance after the start date. */
|
||||
void recurrenceNthInstance(const Recurrence *r, guint n, GDate *date);
|
||||
|
||||
/* Get a time coresponding to the beginning (or end if 'end' is true)
|
||||
/* Get a time corresponding to the beginning (or end if 'end' is true)
|
||||
of the nth instance of the recurrence. Also zero-based. */
|
||||
time64 recurrenceGetPeriodTime(const Recurrence *r, guint n, gboolean end);
|
||||
|
||||
@ -144,7 +144,7 @@ time64 recurrenceGetPeriodTime(const Recurrence *r, guint n, gboolean end);
|
||||
gnc_numeric recurrenceGetAccountPeriodValue(const Recurrence *r,
|
||||
Account *acct, guint n);
|
||||
|
||||
/** @return the earliest of the next occurances -- a "composite" recurrence **/
|
||||
/** @return the earliest of the next occurrences -- a "composite" recurrence **/
|
||||
void recurrenceListNextInstance(const GList *r, const GDate *refDate,
|
||||
GDate *nextDate);
|
||||
|
||||
|
@ -173,9 +173,9 @@ struct timeval
|
||||
* which would generate a flurry of (needless) events, if they
|
||||
* weren't saved up till the commit.
|
||||
* 2) Technically, its incorrect to use transaction data
|
||||
* until the transaction is commited. The GUI element that
|
||||
* until the transaction is committed. The GUI element that
|
||||
* is changing the data can look at it, but all of the rest
|
||||
* of the GUI should ignore the data until its commited.
|
||||
* of the GUI should ignore the data until its committed.
|
||||
*/
|
||||
|
||||
const char *trans_notes_str = "notes";
|
||||
|
@ -153,11 +153,11 @@ QofBackend * xaccTransactionGetBackend (Transaction *trans);
|
||||
/* The xaccEnable/DisableDataScrubbing() routines affect what
|
||||
* happens during transaction commit. When scrubbing is enabled,
|
||||
* then transactions are fixed up during transaction commit,
|
||||
* so that only consistent transactions are commited to the engine.
|
||||
* so that only consistent transactions are committed to the engine.
|
||||
* However, when data is being loaded from a backend (in particular,
|
||||
* from the file backend), the data might not be consistent until
|
||||
* its completely loaded. In particular, gains transactions might
|
||||
* be loaded at a different time than the transactions that casued
|
||||
* be loaded at a different time than the transactions that caused
|
||||
* the gains. Thus, scrubbing needs do be disabled during file
|
||||
* load. These routines enable that.
|
||||
*/
|
||||
|
@ -276,7 +276,7 @@ xaccSplitAssignToLot (Split *split, GNCLot *lot)
|
||||
* implemented accounting policies should be giving us splits
|
||||
* that make lots larger. One a lot is open, the FIFO/LIFO
|
||||
* policies should be working only to make the lot smaller.
|
||||
* We can remove teh warning emssage come the day we have
|
||||
* We can remove the warning emssage come the day we have
|
||||
* fancier policies.
|
||||
*/
|
||||
baln_is_positive = gnc_numeric_positive_p (baln);
|
||||
|
@ -99,7 +99,7 @@ gnc_numeric xaccSplitGetCapGains(Split *);
|
||||
* indicated account is used in the trading of commodities.
|
||||
* A 'trading' account will contain transactions whose
|
||||
* transaction currency is not the same as the account
|
||||
* commodity. The existance of such transactions is
|
||||
* commodity. The existence of such transactions is
|
||||
* the very definition of a 'trade'. This routine returns
|
||||
* TRUE if this is a trading account, else it returns
|
||||
* FALSE.
|
||||
|
@ -25,7 +25,7 @@
|
||||
|
||||
|
||||
|
||||
(define GNC_COMMODITY_NS_CURRENCY "CURRENCY")
|
||||
(define GNC_COMMODITY_NS_CURRENCY (gettext "CURRENCY"))
|
||||
|
||||
;; If you change the C side, change this too.
|
||||
(define GNC_COMMODITY_NS_AMEX "AMEX")
|
||||
@ -33,3 +33,5 @@
|
||||
(define GNC_COMMODITY_NS_NASDAQ "NASDAQ")
|
||||
(define GNC_COMMODITY_NS_EUREX "EUREX")
|
||||
(define GNC_COMMODITY_NS_MUTUAL "FUND")
|
||||
(define GNC_COMMODITY_NS_ASX "ASX")
|
||||
(define GNC_COMMODITY_NS_NONCURRENCY (gettext "ALL NON-CURRENCY"))
|
||||
|
@ -10,7 +10,7 @@ Engine architecture.
|
||||
|
||||
The only remaining architecture flaw is related to the GnuCash XML v2
|
||||
backend modularisation. QofSession includes a dynamic method of loading
|
||||
a QofBackend that supercedes the use of gnc_module_load that currently
|
||||
a QofBackend that supersedes the use of gnc_module_load that currently
|
||||
loads the module using guile/scheme. When the old XML backend is replaced
|
||||
by Sqlite, this will be resolved.
|
||||
|
||||
@ -168,7 +168,7 @@ Many programmers are used to a different interface, e.g.
|
||||
}
|
||||
\endverbatim
|
||||
Because of this, it is important to explain why the former design was
|
||||
choosen over the latter. Let us begin by listing how the choosen design
|
||||
chosen over the latter. Let us begin by listing how the chosen design
|
||||
is as good as, and in many ways can be better to the later design.
|
||||
|
||||
-# Allows programmer to check for errors asynchronously, e.g. outside
|
||||
@ -182,7 +182,7 @@ is as good as, and in many ways can be better to the later design.
|
||||
|
||||
The right implementation for (2) is to implement not a single
|
||||
variable, but a stack or a ring (circular queue) on which error codes
|
||||
are placed, and from which error codes can be retreived. The right
|
||||
are placed, and from which error codes can be retrieved. The right
|
||||
implementation for (3) is the use pthread_getspecific() to define a
|
||||
per-thread global and/or ring/queue.
|
||||
|
||||
@ -303,20 +303,20 @@ course-grained account-group level.
|
||||
|
||||
There is a rudimentary level of "TP" build in, via the routines
|
||||
xaccTransBeginEdit(), xaccTransRollbackEdit(), and xaccTransCommitEdit(),
|
||||
which allow changes to be made to a transaction, and then commited,
|
||||
which allow changes to be made to a transaction, and then committed,
|
||||
or rejected at the end. Handy for the GUI, if the user makes a bunch
|
||||
of changes which they don't want to keep; also handy for an SQL back end,
|
||||
where the Commit() routine triggers the actual update of the SQL database.
|
||||
|
||||
Note: 'Commit' is sometimes called 'post' in other systems: The
|
||||
act of 'commiting' a transaction is the same as 'posting' the
|
||||
act of 'committing' a transaction is the same as 'posting' the
|
||||
transaction to the general journal.
|
||||
|
||||
Some important implementation details to understand: the GUI currently
|
||||
uses begin/end as a convenience, and thus, may hold a transaction in
|
||||
the 'edit' state for a portentially long time (minutes or hours).
|
||||
Thus, begin/end should not map naively to a table-lock/unlock.
|
||||
Instead, an optimistic-locking scheme, as below, is prefered.
|
||||
Instead, an optimistic-locking scheme, as below, is preferred.
|
||||
|
||||
The SQL back-end should implement posting entirely in the
|
||||
'Commit()' routine. The pseudo-algorithms should look as follows:
|
||||
|
@ -48,7 +48,7 @@
|
||||
((account-same? (car accounts) account) #t)
|
||||
(else (account-in-list? account (cdr accounts))))))
|
||||
|
||||
;; Optimized version of accout-in-list if we know
|
||||
;; Optimized version of account-in-list if we know
|
||||
;; the list in advance.
|
||||
(define (account-in-list-pred accounts)
|
||||
(define (my-assoc str alist)
|
||||
|
@ -37,7 +37,7 @@ The xaccPeriodClose() subroutine performs the following:
|
||||
- find the equity account (what if there is more than one equity account
|
||||
?? what if equity has sub-accounts ?? )
|
||||
- transfer all income/expense to equity (shouldn't the equity account
|
||||
match the income/expense heirarchy?)
|
||||
match the income/expense hierarchy?)
|
||||
- return a new account group with new opening balances ...
|
||||
|
||||
\section transactionchanges Changes to Transaction Structure
|
||||
|
@ -1521,7 +1521,7 @@ gnc_commodity_increment_usage_count(gnc_commodity *cm)
|
||||
&& gnc_commodity_get_auto_quote_control_flag(cm)
|
||||
&& gnc_commodity_is_iso(cm))
|
||||
{
|
||||
/* compatability hack - Gnucash 1.8 gets currency quotes when a
|
||||
/* compatibility hack - Gnucash 1.8 gets currency quotes when a
|
||||
non-default currency is assigned to an account. */
|
||||
gnc_commodity_begin_edit(cm);
|
||||
gnc_commodity_set_quote_flag(cm, TRUE);
|
||||
@ -1803,7 +1803,7 @@ gnc_commodity_table_lookup(const gnc_commodity_table * table,
|
||||
if (nsp)
|
||||
{
|
||||
/*
|
||||
* Backward compatability support for currencies that have
|
||||
* Backward compatibility support for currencies that have
|
||||
* recently changed.
|
||||
*/
|
||||
if (nsp->iso4217)
|
||||
@ -1927,7 +1927,7 @@ gnc_commodity_table_insert(gnc_commodity_table * table,
|
||||
return c;
|
||||
}
|
||||
|
||||
/* Backward compatability support for currencies that have
|
||||
/* Backward compatibility support for currencies that have
|
||||
* recently changed. */
|
||||
if (priv->name_space->iso4217)
|
||||
{
|
||||
@ -2117,9 +2117,29 @@ gnc_commodity_is_currency(const gnc_commodity *cm)
|
||||
|
||||
/********************************************************************
|
||||
* gnc_commodity_table_get_commodities
|
||||
* list commodities in a give namespace
|
||||
* list commodities in a given namespace
|
||||
********************************************************************/
|
||||
|
||||
static CommodityList*
|
||||
commodity_table_get_all_noncurrency_commodities(const gnc_commodity_table* table)
|
||||
{
|
||||
GList *node = NULL, *nslist = gnc_commodity_table_get_namespaces(table);
|
||||
CommodityList *retval = NULL;
|
||||
for (node = nslist; node; node=g_list_next(node))
|
||||
{
|
||||
gnc_commodity_namespace *ns = NULL;
|
||||
if (g_strcmp0((char*)(node->data), GNC_COMMODITY_NS_CURRENCY) == 0
|
||||
|| g_strcmp0((char*)(node->data), "template") == 0)
|
||||
continue;
|
||||
ns = gnc_commodity_table_find_namespace(table, (char*)(node->data));
|
||||
if (!ns)
|
||||
continue;
|
||||
retval = g_list_concat(g_hash_table_values(ns->cm_table), retval);
|
||||
}
|
||||
g_list_free(nslist);
|
||||
return retval;
|
||||
}
|
||||
|
||||
CommodityList *
|
||||
gnc_commodity_table_get_commodities(const gnc_commodity_table * table,
|
||||
const char * name_space)
|
||||
@ -2128,7 +2148,8 @@ gnc_commodity_table_get_commodities(const gnc_commodity_table * table,
|
||||
|
||||
if (!table)
|
||||
return NULL;
|
||||
|
||||
if (g_strcmp0(name_space, GNC_COMMODITY_NS_NONCURRENCY) == 0)
|
||||
return commodity_table_get_all_noncurrency_commodities(table);
|
||||
ns = gnc_commodity_table_find_namespace(table, name_space);
|
||||
if (!ns)
|
||||
return NULL;
|
||||
|
@ -97,13 +97,14 @@ GType gnc_commodity_namespace_get_type(void);
|
||||
#define GNC_COMMODITY_NS_LEGACY "GNC_LEGACY_CURRENCIES"
|
||||
/* The ISO define is deprecated in favor of CURRENCY */
|
||||
#define GNC_COMMODITY_NS_ISO "ISO4217"
|
||||
#define GNC_COMMODITY_NS_CURRENCY "CURRENCY"
|
||||
#define GNC_COMMODITY_NS_CURRENCY _("CURRENCY")
|
||||
#define GNC_COMMODITY_NS_NASDAQ "NASDAQ"
|
||||
#define GNC_COMMODITY_NS_NYSE "NYSE"
|
||||
#define GNC_COMMODITY_NS_EUREX "EUREX"
|
||||
#define GNC_COMMODITY_NS_MUTUAL "FUND"
|
||||
#define GNC_COMMODITY_NS_AMEX "AMEX"
|
||||
#define GNC_COMMODITY_NS_ASX "ASX"
|
||||
#define GNC_COMMODITY_NS_NONCURRENCY _("ALL NON-CURRENCY")
|
||||
|
||||
typedef GList CommodityList;
|
||||
|
||||
@ -338,7 +339,7 @@ const char * gnc_commodity_get_namespace(const gnc_commodity * cm);
|
||||
* a pointer to a null terminated string of the form "AMEX",
|
||||
* "NASDAQ", etc. The only difference between function and
|
||||
* gnc_commodity_get_namespace() is that this function returns
|
||||
* ISO4217 instead of CURRENCY for backward compatability with the
|
||||
* ISO4217 instead of CURRENCY for backward compatibility with the
|
||||
* 1.8 data files.
|
||||
*
|
||||
* @param cm A pointer to a commodity data structure.
|
||||
|
@ -26,7 +26,7 @@
|
||||
#define GNC_HOOKS_H
|
||||
|
||||
/**
|
||||
* Create a new hook. Not a common occurrance, but...
|
||||
* Create a new hook. Not a common occurrence, but...
|
||||
* The returned string is just the 'name' argument,
|
||||
* which belongs to the caller.
|
||||
*/
|
||||
|
@ -2,7 +2,7 @@
|
||||
* @file test-engine-stuff.c
|
||||
* @brief tools to set up random, but finanically consistent books.
|
||||
* Create transactions with random values, random accounts, random
|
||||
* account heirarchies, etc.
|
||||
* account hierarchies, etc.
|
||||
*
|
||||
* XXX We should modify routines to create really, ugly, dirty
|
||||
* transactions
|
||||
|
@ -63,7 +63,7 @@ static void test_business (void)
|
||||
do_test (gncBusinessLookup (TEST_MODULE_NAME) == &bus_obj,
|
||||
"lookup our installed object");
|
||||
do_test (gncBusinessLookup ("snm98sn snml say dyikh9y9ha") == NULL,
|
||||
"lookup non-existant business object");
|
||||
"lookup non-existent business object");
|
||||
|
||||
do_test (!g_strcmp0 (gncBusinessGetTypeLabel (TEST_MODULE_NAME),
|
||||
_(TEST_MODULE_DESC)),
|
||||
|
@ -142,7 +142,7 @@ run_test (void)
|
||||
}
|
||||
|
||||
/*
|
||||
* Retore the transaction to its former glory.
|
||||
* Restore the transaction to its former glory.
|
||||
*/
|
||||
xaccTransUnvoid(transaction);
|
||||
|
||||
|
@ -683,7 +683,7 @@ test_gnc_book_set_get_root_account (Fixture *fixture, gconstpointer pData)
|
||||
g_assert (acc1);
|
||||
g_assert (acc1 != fixture->acct);
|
||||
/* Now try to set the book's root account to the fixture
|
||||
* accout. Should throw an error.
|
||||
* account. Should throw an error.
|
||||
*/
|
||||
oldlogger = g_log_set_default_handler ((GLogFunc)test_null_handler, check);
|
||||
g_test_log_set_fatal_handler ((GTestLogFatalFunc)test_checked_handler,
|
||||
@ -701,7 +701,7 @@ test_gnc_book_set_get_root_account (Fixture *fixture, gconstpointer pData)
|
||||
g_assert (gnc_book_get_root_account (book1) != acc1);
|
||||
g_assert (gnc_book_get_root_account (book1) == acc2);
|
||||
/* Clean up */
|
||||
/* acc1 gets freed by setting the root accout to acc2
|
||||
/* acc1 gets freed by setting the root account to acc2
|
||||
g_object_unref (acc1);
|
||||
*/
|
||||
qof_book_destroy (book1);
|
||||
|
@ -657,7 +657,7 @@ test_gnc_book_set_get_root_account (Fixture *fixture, gconstpointer pData)
|
||||
g_assert (acc1);
|
||||
g_assert (acc1 != fixture->acct);
|
||||
/* Now try to set the book's root account to the fixture
|
||||
* accout. Should throw an error.
|
||||
* account. Should throw an error.
|
||||
*/
|
||||
oldlogger = g_log_set_default_handler ((GLogFunc)test_null_handler, &check);
|
||||
g_test_log_set_fatal_handler ((GTestLogFatalFunc)test_checked_handler,
|
||||
|
@ -1707,7 +1707,7 @@ test_xaccSplitGetSharePrice (Fixture *fixture, gconstpointer pData)
|
||||
g_assert (gnc_numeric_equal (result, expected));
|
||||
g_assert_cmpint (check.hits, ==, 0);
|
||||
|
||||
/* Now invent some value/ammount pairs which cause numeric errors to test the limits */
|
||||
/* Now invent some value/amount pairs which cause numeric errors to test the limits */
|
||||
/* This one was supposed to overflow, but it doesn't any more.
|
||||
split->amount = gnc_numeric_create (987654321, 10);
|
||||
split->value = gnc_numeric_create (3, 789304166);
|
||||
|
@ -852,7 +852,7 @@ get_element_widget (GNCSearchWindow *sw, GNCSearchCoreType *element)
|
||||
data->dialog = GTK_DIALOG (sw->dialog);
|
||||
|
||||
hbox = gtk_hbox_new (FALSE, 0);
|
||||
/* only set to automaticaly clean up the memory */
|
||||
/* only set to automatically clean up the memory */
|
||||
g_object_set_data_full (G_OBJECT (hbox), "data", data, g_free);
|
||||
|
||||
p = gnc_search_core_type_get_widget (element);
|
||||
|
@ -87,7 +87,7 @@ typedef struct
|
||||
* Both the param_list and display_list are the property of the dialog
|
||||
* but will NOT be destroyed.. The param_list should be a GList of
|
||||
* GNCSearchParam objects. The display_list should be a GList of
|
||||
* GNCSearchParamSimple objects which defines which paramters
|
||||
* GNCSearchParamSimple objects which defines which parameters
|
||||
* of the found transactions are printed, and how.
|
||||
*
|
||||
* The start_query is the property of the caller and will only be copied.
|
||||
|
@ -592,7 +592,7 @@ subst_insert_amb (gchar *byte_sequence, GList *conv_list, GncXmlImportData *data
|
||||
}
|
||||
else
|
||||
{
|
||||
/* no conversion avaiable, stop filling of subst */
|
||||
/* no conversion available, stop filling of subst */
|
||||
g_hash_table_destroy (data->subst);
|
||||
data->subst = NULL;
|
||||
}
|
||||
@ -1097,7 +1097,7 @@ gxi_parse_file (GncXmlImportData *data)
|
||||
io_err = qof_session_get_error (session);
|
||||
if (io_err == ERR_BACKEND_NO_ERR)
|
||||
{
|
||||
/* loaded sucessfully now. strange, but ok */
|
||||
/* loaded successfully now. strange, but ok */
|
||||
success = TRUE;
|
||||
goto cleanup_parse_file;
|
||||
}
|
||||
|
@ -188,7 +188,7 @@ gnc_account_commodity_from_type (AccountWindow * aw, gboolean update)
|
||||
if (aw->type == ACCT_TYPE_TRADING)
|
||||
new_mode = DIAG_COMM_ALL;
|
||||
else if ((aw->type == ACCT_TYPE_STOCK) || (aw->type == ACCT_TYPE_MUTUAL))
|
||||
new_mode = DIAG_COMM_NON_CURRENCY;
|
||||
new_mode = DIAG_COMM_NON_CURRENCY_SELECT;
|
||||
else
|
||||
new_mode = DIAG_COMM_CURRENCY;
|
||||
|
||||
|
@ -285,6 +285,7 @@ gnc_ui_select_commodity_create(const gnc_commodity * orig_sel,
|
||||
text = _("_Security/currency:");
|
||||
break;
|
||||
case DIAG_COMM_NON_CURRENCY:
|
||||
case DIAG_COMM_NON_CURRENCY_SELECT:
|
||||
title = _("Select security");
|
||||
text = _("_Security:");
|
||||
break;
|
||||
@ -664,6 +665,7 @@ gnc_ui_update_namespace_picker (GtkWidget *cbwe,
|
||||
break;
|
||||
|
||||
case DIAG_COMM_NON_CURRENCY:
|
||||
case DIAG_COMM_NON_CURRENCY_SELECT:
|
||||
namespaces =
|
||||
gnc_commodity_table_get_namespaces (gnc_get_current_commodities());
|
||||
node = g_list_find_custom (namespaces, GNC_COMMODITY_NS_CURRENCY, collate);
|
||||
@ -682,7 +684,13 @@ gnc_ui_update_namespace_picker (GtkWidget *cbwe,
|
||||
namespaces = g_list_prepend (NULL, GNC_COMMODITY_NS_CURRENCY);
|
||||
break;
|
||||
}
|
||||
|
||||
/* First insert "ALL" */
|
||||
if (mode == DIAG_COMM_NON_CURRENCY_SELECT || mode == DIAG_COMM_ALL)
|
||||
{
|
||||
gtk_list_store_append(GTK_LIST_STORE(model), &iter);
|
||||
gtk_list_store_set (GTK_LIST_STORE(model), &iter, 0,
|
||||
GNC_COMMODITY_NS_NONCURRENCY, -1);
|
||||
}
|
||||
/* add them to the combobox */
|
||||
namespaces = g_list_sort(namespaces, collate);
|
||||
for (node = namespaces; node; node = node->next)
|
||||
|
@ -49,6 +49,10 @@ typedef enum
|
||||
of a currency. */
|
||||
DIAG_COMM_NON_CURRENCY, /**< Dialog box should allow selection of
|
||||
anything but a currency. */
|
||||
DIAG_COMM_NON_CURRENCY_SELECT, /**< Dialog box should allow selection of
|
||||
* anything but a currency and should include
|
||||
* the "ALL" namespace to display all such
|
||||
* commodities in a single list. */
|
||||
DIAG_COMM_ALL, /**< Dialog box should allow selection of
|
||||
anything. */
|
||||
} dialog_commodity_mode;
|
||||
|
@ -1764,7 +1764,7 @@ gnc_options_dialog_new_modal(gboolean modal, gchar *title)
|
||||
gtk_widget_hide (apply_button);
|
||||
}
|
||||
|
||||
/* glade doesn't suport a notebook with zero pages */
|
||||
/* glade doesn't support a notebook with zero pages */
|
||||
hbox = GTK_WIDGET(gtk_builder_get_object (builder, "notebook placeholder"));
|
||||
retval->notebook = gtk_notebook_new();
|
||||
gtk_widget_show(retval->notebook);
|
||||
|
@ -212,7 +212,7 @@ void gnc_xfer_dialog_set_txn_cb(XferDialog *xferData,
|
||||
specified by xfer_com.
|
||||
|
||||
The 'exch_rate' argument is used to set the initial value of the
|
||||
rate. If the dialog completes sucessfully 'FALSE' is returned and
|
||||
rate. If the dialog completes successfully 'FALSE' is returned and
|
||||
'exch_rate' is also used to store the converted value. Otherwise,
|
||||
TRUE is returned and the 'exch_rate' argument is undefined.
|
||||
*/
|
||||
|
@ -3,7 +3,7 @@
|
||||
*
|
||||
* Note that this widget will track changes in the account tree, and update
|
||||
* itself accordingly. If an account with the same name exists in the
|
||||
* freshly-retreived account list, the widget will re-select that account.
|
||||
* freshly-retrieved account list, the widget will re-select that account.
|
||||
*
|
||||
* Copyright (C) 2002 Joshua Sled <jsled@asynchronous.org>
|
||||
* Copyright (c) 2006 David Hampton <hampton@employees.org>
|
||||
|
@ -602,7 +602,7 @@ menuitem_response_cb (GtkMenuItem *item, gpointer *user_data )
|
||||
gtk_label_set_text(GTK_LABEL(priv->label), label_text);
|
||||
gtk_misc_set_alignment (GTK_MISC(priv->label), 0, 0.5);
|
||||
|
||||
/* Get the coresponding entry in the list store */
|
||||
/* Get the corresponding entry in the list store */
|
||||
valid = gtk_tree_model_get_iter_first (priv->model, &iter);
|
||||
while (valid)
|
||||
{
|
||||
@ -690,7 +690,7 @@ gnc_combott_set_active (GncCombott *combott, gint index)
|
||||
}
|
||||
else
|
||||
{
|
||||
/* Get the coresponding entry in the list store */
|
||||
/* Get the corresponding entry in the list store */
|
||||
valid = gtk_tree_model_get_iter_first (priv->model, &iter);
|
||||
while (valid)
|
||||
{
|
||||
|
@ -58,6 +58,7 @@
|
||||
#include "config.h"
|
||||
|
||||
#include <gtk/gtk.h>
|
||||
#include <glib/gi18n.h>
|
||||
#include <string.h>
|
||||
#include <ctype.h>
|
||||
#include <stdio.h>
|
||||
|
@ -4,7 +4,7 @@
|
||||
* Copyright (C) 1997, 1998, 1999, 2000 Free Software Foundation
|
||||
* All rights reserved.
|
||||
*
|
||||
* This file was part of the Gnome Library. It was modifed by
|
||||
* This file was part of the Gnome Library. It was modified by
|
||||
* Dave Peticolas <dave@krondo.com> for use in GnuCash.
|
||||
*
|
||||
* GnuCash is free software; you can redistribute it and/or modify
|
||||
|
@ -34,7 +34,7 @@ G_BEGIN_DECLS
|
||||
#define GNC_IS_DENSE_CAL_MODEL(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GNC_TYPE_DENSE_CAL_MODEL))
|
||||
#define GNC_DENSE_CAL_MODEL_GET_INTERFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst), GNC_TYPE_DENSE_CAL_MODEL, GncDenseCalModelIface))
|
||||
|
||||
typedef struct _GncDenseCalModel GncDenseCalModel; /* non existant */
|
||||
typedef struct _GncDenseCalModel GncDenseCalModel; /* non existent */
|
||||
typedef struct _GncDenseCalModelIface
|
||||
{
|
||||
GTypeInterface parent;
|
||||
|
@ -962,7 +962,7 @@ gnc_dense_cal_draw_to_buffer(GncDenseCal *dcal)
|
||||
}
|
||||
LOG_AND_RESET(timer, "alternating month colors");
|
||||
|
||||
/* Hilight the marked days. */
|
||||
/* Highlight the marked days. */
|
||||
{
|
||||
int i;
|
||||
int x1, x2, y1, y2;
|
||||
@ -1015,7 +1015,7 @@ gnc_dense_cal_draw_to_buffer(GncDenseCal *dcal)
|
||||
cairo_rectangle (cr, x + 0.5, y + 0.5, w, h);
|
||||
cairo_stroke (cr);
|
||||
|
||||
/* draw the week seperations */
|
||||
/* draw the week separations */
|
||||
for (j = 0; j < num_weeks_per_col(dcal); j++)
|
||||
{
|
||||
gint wy = y + (j * week_height(dcal));
|
||||
@ -1024,7 +1024,7 @@ gnc_dense_cal_draw_to_buffer(GncDenseCal *dcal)
|
||||
cairo_stroke (cr);
|
||||
}
|
||||
|
||||
/* draw the day seperations */
|
||||
/* draw the day separations */
|
||||
for (j = 1; j < 7; j++)
|
||||
{
|
||||
gint dx = x + (j * day_width(dcal));
|
||||
|
@ -65,7 +65,7 @@ void gnc_launch_assoc (const char *uri);
|
||||
*/
|
||||
void gnc_options_dialog_set_book_options_help_cb (GNCOptionWin *win);
|
||||
|
||||
/** Set the intial values of new book options to values specified in user
|
||||
/** Set the initial values of new book options to values specified in user
|
||||
* preferences.
|
||||
*/
|
||||
void gnc_options_dialog_set_new_book_option_values (GNCOptionDB *odb);
|
||||
|
@ -90,7 +90,7 @@ GncPlugin *gnc_plugin_file_history_new (void);
|
||||
*/
|
||||
void gnc_history_add_file (const char *filename);
|
||||
|
||||
/** Remove all occurences of a file name from the history list. Move
|
||||
/** Remove all occurrences of a file name from the history list. Move
|
||||
* the other key values up in the list to fill the gaps.
|
||||
*
|
||||
* @param oldfile The name of the file to remove from the list.
|
||||
|
@ -344,7 +344,7 @@ gnc_query_view_init_view (GNCQueryView *qview)
|
||||
else if (((GNCSearchParam *) param)->justify == GTK_JUSTIFY_RIGHT)
|
||||
algn = 1.0;
|
||||
|
||||
/* Set column resizeable */
|
||||
/* Set column resizable */
|
||||
if (((GNCSearchParam *) param)->non_resizeable)
|
||||
{
|
||||
gtk_tree_view_column_set_resizable (col, FALSE);
|
||||
|
@ -73,11 +73,11 @@ extern "C" {
|
||||
GtkTreeViewClass view_class;
|
||||
|
||||
/* This signal is emitted when a toggle happens, the pointer has
|
||||
an interger value for the active setting of the toggle */
|
||||
an integer value for the active setting of the toggle */
|
||||
void (*column_toggled) (GNCQueryView *qview, gpointer item);
|
||||
|
||||
/* This signal is emitted when a row is selected, the pointer has
|
||||
an interger value for the number of rows selected */
|
||||
an integer value for the number of rows selected */
|
||||
void (*row_selected) (GNCQueryView *qview, gpointer item);
|
||||
|
||||
/* This signal is emitted when a row is double clicked, the pointer has
|
||||
|
@ -1092,10 +1092,10 @@ gnc_tree_view_account_get_view_info (GncTreeViewAccount *account_view,
|
||||
* Set the account view info data in use by the specified tree to
|
||||
* match the callers request.
|
||||
*
|
||||
* DRH - COMPATABILITY WARNING
|
||||
* DRH - COMPATIBILITY WARNING
|
||||
*
|
||||
* This function does not do anything with the 'include_type' field.
|
||||
* Should there be a automatic filter for backward compatability
|
||||
* Should there be a automatic filter for backward compatibility
|
||||
* that uses these flags, or should all uses of this be converted to
|
||||
* a GtkTreeModelFilter?
|
||||
*
|
||||
|
@ -1486,7 +1486,7 @@ gtv_sr_cdf0 (GtkTreeViewColumn *col, GtkCellRenderer *cell, GtkTreeModel *s_mode
|
||||
if ((view->priv->current_trans == trans) && view->priv->show_extra_dates_on_selection)
|
||||
show_extra_dates = TRUE;
|
||||
|
||||
// Show the extra dates allways
|
||||
// Show the extra dates always
|
||||
if (view->show_extra_dates == TRUE)
|
||||
show_extra_dates = TRUE;
|
||||
|
||||
@ -3600,7 +3600,7 @@ gtv_sr_button_cb (GtkWidget *widget, GdkEventButton *event, gpointer user_data)
|
||||
if (event->window != window)
|
||||
return FALSE;
|
||||
|
||||
// Make sure we have stoped editing.
|
||||
// Make sure we have stopped editing.
|
||||
gnc_tree_view_split_reg_finish_edit (view);
|
||||
|
||||
// This prevents the cell changing.
|
||||
@ -5066,7 +5066,7 @@ gtv_sr_num_cb (GtkEntry *entry,
|
||||
}
|
||||
|
||||
|
||||
/* Callback for Account seperator key */
|
||||
/* Callback for Account separator key */
|
||||
static void
|
||||
gtv_sr_acct_cb (GtkEntry *entry,
|
||||
const gchar *text,
|
||||
|
@ -156,7 +156,7 @@ void gnc_search_param_override_param_type (GNCSearchParamSimple *param,
|
||||
* Helper functions ..
|
||||
*/
|
||||
|
||||
/* Create a paramter and prepend it to a GSList */
|
||||
/* Create a parameter and prepend it to a GSList */
|
||||
GList * gnc_search_param_prepend (GList *list, char const *title,
|
||||
QofIdTypeConst type_override,
|
||||
QofIdTypeConst search_type,
|
||||
@ -176,7 +176,7 @@ GList * gnc_search_param_prepend_compound (GList *list, char const *titl
|
||||
|
||||
/* set a lookup function for this parameter (in lieu of setting the
|
||||
* param path) if you want to specify a direct lookup function when
|
||||
* using the compute_value interface. Note that this wont work with
|
||||
* using the compute_value interface. Note that this won't work with
|
||||
* sorting or other query interfaces, it's only useful for the
|
||||
* query-list.
|
||||
*/
|
||||
|
@ -96,7 +96,7 @@ void ap_assistant_cancel (GtkAssistant *gtkassistant, gpointer us
|
||||
void ap_assistant_close (GtkAssistant *gtkassistant, gpointer user_data);
|
||||
|
||||
/* =============================================================== */
|
||||
/* Find the earliest date occuring in the book. Do this by making
|
||||
/* Find the earliest date occurring in the book. Do this by making
|
||||
* a query and sorting by date. Since the truncated sort returns
|
||||
* only the *last* search results, sort in decreasing order.
|
||||
*/
|
||||
@ -139,7 +139,7 @@ get_earliest_in_book (QofBook *book)
|
||||
}
|
||||
|
||||
/* =============================================================== */
|
||||
/* Find the number of transactions occuring before the indicated date.
|
||||
/* Find the number of transactions occurring before the indicated date.
|
||||
* Do this by making a query and counting the results.
|
||||
*/
|
||||
|
||||
@ -294,7 +294,7 @@ ap_assistant_menu_prepare (GtkAssistant *assistant, gpointer user_data)
|
||||
period_begin = period_end;
|
||||
recurrenceListNextInstance(info->period, &period_begin, &period_end);
|
||||
|
||||
/* FIXME Check for valid period_end, not sure why it wont be!!! */
|
||||
/* FIXME Check for valid period_end, not sure why it won't be!!! */
|
||||
if (g_date_valid (&period_end) != TRUE)
|
||||
break;
|
||||
}
|
||||
@ -493,7 +493,7 @@ ap_assistant_finish (GtkAssistant *assistant, gpointer user_data)
|
||||
&info->closing_date);
|
||||
|
||||
|
||||
/* FIXME Test for valid closing date, not sure why it wont be!!! */
|
||||
/* FIXME Test for valid closing date, not sure why it won't be!!! */
|
||||
if (g_date_valid(&info->closing_date) == TRUE)
|
||||
{
|
||||
/* If the next closing date is in the future, then we are done. */
|
||||
|
@ -582,7 +582,7 @@ gnc_loan_assistant_create( LoanAssistantData *ldd )
|
||||
GList *allowableAccounts;
|
||||
} gas_data[] =
|
||||
{
|
||||
/* These ints are the GtkTable boundries */
|
||||
/* These ints are the GtkTable boundaries */
|
||||
{ &ldd->prmAccountGAS, ldd->prmTable, TRUE, 1, 4, 0, 1, liabilityAcct },
|
||||
{ &ldd->repAssetsFromGAS, ldd->repTable, TRUE, 1, 4, 2, 3, paymentFromAccts },
|
||||
{ &ldd->repPrincToGAS, ldd->repTable, TRUE, 1, 2, 3, 4, paymentToAccts },
|
||||
@ -644,7 +644,7 @@ gnc_loan_assistant_create( LoanAssistantData *ldd )
|
||||
int left, right, top, bottom;
|
||||
} gde_data[] =
|
||||
{
|
||||
/* These ints are the GtkTable boundries */
|
||||
/* These ints are the GtkTable boundaries */
|
||||
{ &ldd->prmStartDateGDE, ldd->prmTable, 1, 2, 4, 5 },
|
||||
{ &ldd->revStartDate, ldd->revTable, 1, 2, 0, 1 },
|
||||
{ &ldd->revEndDate, ldd->revTable, 1, 2, 1, 2 },
|
||||
|
@ -192,7 +192,7 @@ gnc_ui_find_transactions_dialog_create(GNCLedgerDisplay * orig_ledg)
|
||||
|
||||
/* In lieu of not "mis-using" some portion of the infrastructure by writing
|
||||
* a bunch of new code, we just filter out the accounts of the template
|
||||
* transactions. While these are in a seperate Account trees just for this
|
||||
* transactions. While these are in a separate Account trees just for this
|
||||
* reason, the query engine makes no distinction between Account trees.
|
||||
* See Gnome Bug 86302.
|
||||
* -- jsled
|
||||
|
@ -193,7 +193,7 @@ gnc_ui_find_transactions_dialog_create2 (GNCLedgerDisplay2 * orig_ledg)
|
||||
|
||||
/* In lieu of not "mis-using" some portion of the infrastructure by writing
|
||||
* a bunch of new code, we just filter out the accounts of the template
|
||||
* transactions. While these are in a seperate Account trees just for this
|
||||
* transactions. While these are in a separate Account trees just for this
|
||||
* reason, the query engine makes no distinction between Account trees.
|
||||
* See Gnome Bug 86302.
|
||||
* -- jsled
|
||||
|
@ -1469,7 +1469,7 @@ read_one_check_format(PrintCheckDialog *pcd, const gchar *groupname,
|
||||
|
||||
|
||||
/* Iterate over a single check directory, throwing out any backup files and
|
||||
* then calling a helper function to read and parse the check format withing
|
||||
* then calling a helper function to read and parse the check format within
|
||||
* the file.
|
||||
*/
|
||||
static void
|
||||
|
@ -246,7 +246,7 @@ editor_ok_button_clicked_cb( GtkButton *b, GncSxEditorDialog *sxed )
|
||||
gnc_sxed_save_sx( sxed );
|
||||
|
||||
/* add to list */
|
||||
// @@fixme -- forget 'new'-flag: check for existance of the SX [?]
|
||||
// @@fixme -- forget 'new'-flag: check for existence of the SX [?]
|
||||
if ( sxed->newsxP )
|
||||
{
|
||||
book = gnc_get_current_book ();
|
||||
@ -1079,7 +1079,7 @@ scheduledxaction_editor_dialog_destroy(GtkWidget *object, gpointer data)
|
||||
{
|
||||
/* FIXME: WTF???
|
||||
*
|
||||
* "WTF" explaination: in the "new" click from the caller, we
|
||||
* "WTF" explanation: in the "new" click from the caller, we
|
||||
* set this flag. When "ok" is pressed on the dialog, we set
|
||||
* this flag to false, and thus leave the SX live. If
|
||||
* "Cancel" is clicked, the flag will still be true, and this
|
||||
|
@ -245,7 +245,7 @@ editor_ok_button_clicked_cb (GtkButton *b, GncSxEditorDialog2 *sxed)
|
||||
gnc_sxed_save_sx (sxed);
|
||||
|
||||
/* add to list */
|
||||
// @@fixme -- forget 'new'-flag: check for existance of the SX [?]
|
||||
// @@fixme -- forget 'new'-flag: check for existence of the SX [?]
|
||||
if ( sxed->newsxP )
|
||||
{
|
||||
book = gnc_get_current_book ();
|
||||
@ -1049,7 +1049,7 @@ scheduledxaction_editor_dialog_destroy (GtkWidget *object, gpointer data)
|
||||
{
|
||||
/* FIXME: WTF???
|
||||
*
|
||||
* "WTF" explaination: in the "new" click from the caller, we
|
||||
* "WTF" explanation: in the "new" click from the caller, we
|
||||
* set this flag. When "ok" is pressed on the dialog, we set
|
||||
* this flag to false, and thus leave the SX live. If
|
||||
* "Cancel" is clicked, the flag will still be true, and this
|
||||
|
@ -107,7 +107,7 @@ static GncSxInstances* _gnc_sx_slr_tree_model_adapter_get_sx_instances(GncSxSlrT
|
||||
/** @return null if the iter is not actually an GncSxInstance. **/
|
||||
GncSxInstance* gnc_sx_slr_model_get_instance(GncSxSlrTreeModelAdapter *model, GtkTreeIter *iter);
|
||||
static GncSxInstance* _gnc_sx_slr_model_get_instance(GncSxSlrTreeModelAdapter *model, GtkTreeIter *iter, gboolean check_depth);
|
||||
/** @return false if the iter is not actaully an GncSxInstance's variable. **/
|
||||
/** @return false if the iter is not actually an GncSxInstance's variable. **/
|
||||
gboolean gnc_sx_slr_model_get_instance_and_variable(GncSxSlrTreeModelAdapter *model, GtkTreeIter *iter, GncSxInstance **instance_loc, GncSxVariable **var_loc);
|
||||
|
||||
void gnc_sx_slr_model_effect_change(GncSxSlrTreeModelAdapter *model, gboolean auto_create_only, GList **created_transaction_guids, GList **creation_errors);
|
||||
|
@ -1043,7 +1043,7 @@ impl_webkit_copy_to_clipboard( GncHtml* self )
|
||||
*
|
||||
* @param self GncHtmlWebkit object
|
||||
* @param filepath Where to write the HTML
|
||||
* @return TRUE if successful, FALSE if unsucessful
|
||||
* @return TRUE if successful, FALSE if unsuccessful
|
||||
**************************************************************/
|
||||
static gboolean
|
||||
impl_webkit_export_to_file( GncHtml* self, const char *filepath )
|
||||
|
@ -79,7 +79,7 @@ typedef gboolean (* GncHTMLUrlCB)(const gchar* location, const gchar* label,
|
||||
|
||||
/**
|
||||
* Registers a new URLType.
|
||||
* returns TRUE if succesful, FALSE if type already exists.
|
||||
* returns TRUE if successful, FALSE if type already exists.
|
||||
*
|
||||
* @param type New URL type
|
||||
* @param prococol Protocol - should be an empty string if there is no corresponding protocol.
|
||||
|
@ -571,7 +571,7 @@ csv_export_end_date_cb (GtkWidget *radio, gpointer user_data)
|
||||
/*******************************************************************
|
||||
* get_earliest_in_book
|
||||
*
|
||||
* Find the earliest date occuring in the book. Do this by making
|
||||
* Find the earliest date occurring in the book. Do this by making
|
||||
* a query and sorting by date. Since the truncated sort returns
|
||||
* only the *last* search results, sort in decreasing order.
|
||||
*******************************************************************/
|
||||
|
@ -61,7 +61,7 @@ enum GncCsvLineType {TRANS_SIMPLE,
|
||||
* write_line_to_file
|
||||
*
|
||||
* write a text string to a file pointer, return TRUE if
|
||||
* successfull.
|
||||
* successful.
|
||||
*******************************************************/
|
||||
static
|
||||
gboolean write_line_to_file (FILE *fh, char * line)
|
||||
|
@ -52,7 +52,7 @@ static QofLogModule log_module = GNC_MOD_ASSISTANT;
|
||||
* write_line_to_file
|
||||
*
|
||||
* write a text string to a file pointer, return TRUE if
|
||||
* successfull.
|
||||
* successful.
|
||||
*******************************************************/
|
||||
static
|
||||
gboolean write_line_to_file (FILE *fh, char * line)
|
||||
|
@ -1404,7 +1404,7 @@ static void treeview_resized (GtkWidget* widget, GtkAllocation* allocation, CsvI
|
||||
|
||||
/* Get the width. */
|
||||
col_width = gtk_tree_view_column_get_width (gtk_tree_view_get_column (info->treeview, i));
|
||||
/* Set the minumum width for a column so that drop down selector can be seen. */
|
||||
/* Set the minimum width for a column so that drop down selector can be seen. */
|
||||
if (col_width < MIN_COL_WIDTH)
|
||||
{
|
||||
col_width = MIN_COL_WIDTH;
|
||||
@ -1842,7 +1842,7 @@ static void gnc_csv_preview_update_assist (CsvImportTrans* info)
|
||||
GList *tv_columns, *tv_columns_begin, *ctv_columns, *ctv_columns_begin;
|
||||
tv_columns = tv_columns_begin = gtk_tree_view_get_columns (info->treeview);
|
||||
ctv_columns = ctv_columns_begin = gtk_tree_view_get_columns (info->ctreeview);
|
||||
/* Clear out exisiting columns in info->treeview. */
|
||||
/* Clear out existing columns in info->treeview. */
|
||||
while (tv_columns != NULL)
|
||||
{
|
||||
gtk_tree_view_remove_column (info->treeview, GTK_TREE_VIEW_COLUMN(tv_columns->data));
|
||||
|
@ -30,7 +30,7 @@ enum gnc_match_probability {
|
||||
}
|
||||
|
||||
Here is the pseudocode of the gnc_import_add_trans function:
|
||||
Variables: matches (a list of possible match with likelyhood)
|
||||
Variables: matches (a list of possible match with likelihood)
|
||||
split_to_match = trans's first split.
|
||||
|
||||
In split_to_match's parent account; for each split where date >= split_to_match.date - 2 months:
|
||||
@ -49,7 +49,7 @@ In split_to_match's parent account; for each split where date >= split_to_match.
|
||||
else
|
||||
add to matches using UNLIKELY
|
||||
|
||||
Present the list of matches to the user in decreasing order of likelyhood. User has the option of selecting one of the match or creating a new transaction.
|
||||
Present the list of matches to the user in decreasing order of likelihood. User has the option of selecting one of the match or creating a new transaction.
|
||||
Add transaction_online_id to selected split
|
||||
Erase from other CERTAIN splits
|
||||
if transaction not balanced
|
||||
|
@ -429,7 +429,7 @@ TransactionGetTokens(GNCImportTransInfo *info)
|
||||
text = xaccTransGetDescription(transaction);
|
||||
tokens = tokenize_string(tokens, text);
|
||||
|
||||
/* The day of week the transaction occured is a good indicator of
|
||||
/* The day of week the transaction occurred is a good indicator of
|
||||
* what account this transaction belongs in. Get the date and covert
|
||||
* it to day of week as a token
|
||||
*/
|
||||
@ -647,7 +647,7 @@ static void split_find_match (GNCImportTransInfo * trans_info,
|
||||
{
|
||||
/* If a transaction's amount doesn't match within the
|
||||
threshold, it's very unlikely to be the same transaction
|
||||
so we give it an extra -5 penality */
|
||||
so we give it an extra -5 penalty */
|
||||
prob = prob - 5;
|
||||
/* DEBUG("heuristics: probability - 1 (amount)"); */
|
||||
}
|
||||
@ -721,7 +721,7 @@ static void split_find_match (GNCImportTransInfo * trans_info,
|
||||
else if (strlen(new_trans_str) > 0 && strlen(split_str) > 0)
|
||||
{
|
||||
/* If both number are not empty yet do not match, add a
|
||||
little extra penality */
|
||||
little extra penalty */
|
||||
prob -= 2;
|
||||
}
|
||||
}
|
||||
@ -837,11 +837,11 @@ void gnc_import_find_split_matches(GNCImportTransInfo *trans_info,
|
||||
TRUE, download_time + match_date_hardlimit * 86400,
|
||||
QOF_QUERY_AND);
|
||||
list_element = qof_query_run (query);
|
||||
/* Sigh. Doesnt help too much. We still create and run one query
|
||||
/* Sigh. Doesn't help too much. We still create and run one query
|
||||
for each imported transaction. Maybe it would improve
|
||||
performance further if there is one single (master-)query at
|
||||
the beginning, matching the full date range and all accounts in
|
||||
question. However, this doesnt quite work because this function
|
||||
question. However, this doesn't quite work because this function
|
||||
here is called from each gnc_gen_trans_list_add_trans(), which
|
||||
is called one at a time. Therefore the whole importer would
|
||||
have to change its behaviour: Accept the imported txns via
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user