Re: Slow Scrolling with latest OS X Binary
Actually, my gripe is increasing; I have found that the reconcile window arrow key response is HORRIBLE (3 seconds to move the focus down one line). There is clearly something seriously wrong in there. This was not a problem in the earlier dmg file. David --- On Wed, 9/2/09, David T. sunfis...@yahoo.com wrote: From: David T. sunfis...@yahoo.com Subject: Slow Scrolling with latest OS X Binary To: devel gnucash gnucash-devel@gnucash.org Date: Wednesday, September 2, 2009, 5:41 PM I know it's a minor gripe, but the scrolling in the latest OS X binary (downloaded yesterday) is extremely slow. I am running 10.5.8 on a Macbook Pro Intel. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reg Run Balance for Subaccount view
OK, IMO the updated patch attached to this mail is ready for testing. This patch does the following: 1. When opening an account register and it's subaccounts by right clicking it in the Accounts tab and selecting Open Subaccounts, there is now a Balance column as there normally is in a single account register. 2. This new RBALN balance column tallies the balance of the splits for the account and all subaccounts at runtime. 3. Because the balance is calculated at runtime, this also means that the balance column always reflects an accurate running balance regardless of sort order. This is a big benefit and could certainly be modified to work for single account view as well. With the current single account register, when the sort order is changed the Balance displayed will only reflect the balance of the account associated with each split - not a running balance in relation to the sort order of the register, so that the 'Balance' displayed for each split when the sort order is not the default causes the 'Balance' column to be more or less unusable. I believe this should also resolve the following issue: http://bugzilla.gnome.org/show_bug.cgi?id=107929 I resolved issue #1 in my original mailing list post. Issue #2 remains a matter of testing by other users to ensure the patch doesn't have any unintended consequences. I've tested this patch locally by opening an account and it's subaccounts using the Open Subaccounts option. The newly added balance column tallies the balance properly at runtime, and sets the balance color properly as well (red for negative, black positive). I also tested different sort orders, and the running balance was spot on regardless. Since this affects only the Open Subaccounts register (and possibly other similar registers?), this does not affect single account registers so those still do not tally Balance properly when using a non-default sort order. This patch is against an older version of the SVN repository (I think a trunk snapshot of version 3.1), so it may or may not work OK with the latest trunk. Let me know if I need to make a new patch with the current trunk. As a side note and as matter of cleanup, it would be useful to functionalize the part of the new gnc_split_register_get_rbaln_entry() function which does the actual calculations to get the running balance of the register at a specific split, because the running balance also has to be calculated for the gnc_split_register_get_balance_fg_color() function to set the text color properly when the RBALN cell type is used. Currently I've just copied the code from the rbaln function to the fg_color function, so it would be helpful to put this in a function that returns a gnu_numeric value of the split's running balance for the register which could then be called by both functions. However, I'm not an experienced C programmer so I was having some trouble figuring out just where to put such a function and how to get it working. I did try! Also, this is my first FOSS patch, so let me know if there is anything I can do differently or improve on, thanks! -Tim M. On Fri, Jul 10, 2009 at 10:53 AM, Tim M t...@filmchicago.org wrote: Hello, I've attached a BETA svn diff patch against HEAD which creates a new cell type, RBALN_CELL. I could use some help tweaking this patch if someone is able to provide answers to my questions below. This cell calculates the balance of all transactions in a register at runtime, allowing a running balance to be displayed when using the Open Subaccounts feature. The cell currently calculates the running balance of all splits that are going to/from the lead account and all of its subaccounts, therefore it is not appropriate (currently) to use this cell type in a non-subaccount register view. My Questions: 1. There is an outstanding issue with this patch where it appears the return value of the gnc_split_register_get_rbaln_entry() function is printed in the Balance column of the split rows. The running Balance is correctly printed on the Transaction rows, but the cells in the Balance column on the lines of the split should be blank. Instead, they display 1 (for all transactions where a balance is printed) or 0 (for the blank split at the bottom because the function returns NULL since we don't print the balance for that txn). How can I fix this so that the balance cell of the split lines is blank? 2. The RBALN_CELL was added to the CURSOR_SINGLE_JOURNAL cursor of the INCOME_LEDGER/GENERAL_LEDGER/SEARCH_LEDGER cases in split-register-layout.c. Will this affect other register views besides the subaccount view? I have only tested this with asset accounts (bank, checking) so I'm not sure if it might cause problems with different account types. Please take a look and let me know how I can further improve it! Thanks, -Tim M. Index: src/register/ledger-core/split-register-model.c === ---
[PATCH] python binding improvements
Ahh, finally.
Attached are patches to the python bindings that I've actually had for
awhile. Sending them upstream was somebody else's responsibility for so
long that they were out of my field of attention once responsibility
changed.
Today I opened up ParIT's svn repository, so if we're ever foolishly
hoarding things again, you guys can just pull from us
http://svn.parit.ca/financial/gnucash
Our python binding work is in
http://svn.parit.ca/financial/gnucash/branches/python-bindings-2009-trunk
Apparently there's more work sitting in a working copy on the hard drive
of a former colleague, some of which might even be the .i redundancy
work that Derek suggested we engage in. I've this guy as another
reminder that I'd really like to get my hands on that work, polish it,
and get it here upstream where it belongs.
So, the patches are (in order of application)
python_GetNthChild_remove.patch
remove the redundant GetNthChild code, gnc_account_nth_child supported
python_more_GUID.patch
Improve support for GUID
python_better_commodity.patch
* Removed custom __init__ from GncCommodity, not only is it wrong but
the one
from GnuCashCoreClass is just fine.
* Supported the get_table method For Book
* Removed support for direct instantiation of GncCommodityTable. (via
gnc_commodity_table_new() ). Only methods and not the constructor
function are added to the class now. Python binding users can access a
GncCommodityTable instance via Book.get_table() and have no need to use
gnc_commodity_table_new(), which the apis advise is for internal use
only.
python_GncLot.patch
* included gnc-lot.h in gnucash_core.i again
* Made GncLot class use superclass __init__, it doesn't need its own.
python_more_documentation.patch
Documentation strings for many classes, which can be viewed in source
and with python's help() mechanism.
python_business_module_load.patch
load the business module, not the business module specific backend
python_example_scripts.py
example scripts improved, new one added. This new script originally
came from this post:
http://lists.gnucash.org/pipermail/gnucash-devel/2008-July/023618.html
python_authors_update.patch
added Legal Aid Manitoba to credit line for Mark Jenkins
My funding is coming from Legal Aid Manitoba, which has a very
successful free software deployment. They are looking forward to adding
GnuCash to their mix.
http://www.informit.com/articles/article.aspx?p=30590
I'd like to know if anyone has any trouble using
--enable-python-bindings. Remember to use gnucash-env and to include the
directory containing the python gnucash module directory in your
PYTHONPATH.
Mark Jenkins
Member
ParIT Worker Co-operative
cc Scott Balneaves, Legal Aid Manitoba
cc fellow ParITistas
Index: src/optional/python-bindings/gnucash_core.py
===
--- src/optional/python-bindings/gnucash_core.py (revision 380)
+++ src/optional/python-bindings/gnucash_core.py (revision 381)
@@ -135,8 +135,6 @@
class Account(GnuCashCoreClass):
_new_instance = 'xaccMallocAccount'
-def GetNthChild(self, n):
-return self.get_children().pop(n)
class GUID(GnuCashCoreClass):
_new_instance = 'guid_new_return'
@@ -278,7 +276,6 @@
'nth_child' : Account,
'lookup_by_name' : Account,
'lookup_by_full_name' : Account,
-'GetNthChild' : Account,
'FindTransByDesc' : Transaction,
'FindSplitByDesc' : Split,
'get_start_balance' : GncNumeric,
Index: src/optional/python-bindings/gnucash_core.py
===
--- src/optional/python-bindings/gnucash_core.py (revision 381)
+++ src/optional/python-bindings/gnucash_core.py (revision 382)
@@ -222,6 +222,7 @@
# Transaction
Transaction.add_methods_with_prefix('xaccTrans')
+Transaction.add_method('gncTransGetGUID', 'GetGUID');
trans_dict ={
'GetSplit': Split,
@@ -235,12 +236,14 @@
'GetAccountAmount': GncNumeric,
'GetAccountConvRate': GncNumeric,
'GetAccountBalance': GncNumeric,
-'GetCurrency': GncCommodity
+'GetCurrency': GncCommodity,
+'GetGUID': GUID
}
methods_return_instance(Transaction, trans_dict)
# Split
Split.add_methods_with_prefix('xaccSplit')
+Split.add_method('gncSplitGetGUID', 'GetGUID');
split_dict ={
'GetBook': Book,
@@ -257,7 +260,8 @@
'GetClearedBalance': GncNumeric,
'GetReconciledBalance': GncNumeric,
'VoidFormerAmount': GncNumeric,
-'VoidFormerValue': GncNumeric
+'VoidFormerValue': GncNumeric,
+'GetGUID': GUID
}
