marcnshap at gmail.com
Sat May 31 18:16:18 EDT 2014
And I did it again!
Sorry, John and David.
On 05/31/2014 03:14 PM, Marc Shapiro wrote:
> Ooops! I meant to send this to the list.
> All in all it sounds like it would be a lot more work that I am really
> up to at this time. Of course, learning Scheme/Guile is not really
> any better.
> What I want is to be able to generate a Balance Sheet with all current
> transactions, then add in any budget items and/or future transactions
> up to an arbitrary date in the future to project all of the Balance
> Sheet accounts as of that arbitrary future date.
> It seems like it shouldn't be difficult to merge the Budget and Future
> Transaction info from their reports into the Balance Sheet if I
> already knew Guile. Unfortunately, I don't know Guile. LISP and its
> derivatives are just way too different from, say, C/C++ or Python for
> me to easily get the hang of it.
> On 05/31/2014 01:01 PM, David Osguthorpe wrote:
>> On Sat, May 31, 2014 at 12:27:25PM -0700, John Ralls wrote:
>>> Why not instead add python to the swig files for the API that you
>>> need? It's only one header, gnc-budget.h, and you can use the Guile
>>> adapter code in src/engine/engine.i as a guide.
>> not quite as simple as this - I added gnc-budget.h to gnucash_core.i
>> - yes you get the GncBudget bindings but you also need access to
>> Reccurence.h which uses GDates
>> which needs adding a gdate.i for type wrapping
>> plus the only budget lookup function in GncBudget does it by GUID
>> - to lookup by budget name needs a Qof Query - yes the qof query
>> exist but the result of query run is a GList of arbitrary type objects
>> which I didnt figure a good way of retyping so far - except by assuming
>> all GList entries are budgets and creating a wrapper to the base
>> query run to which the GList entry type is passed
>> - but still dont really like this yet
> On 05/31/2014 12:55 PM, David Osguthorpe wrote:
>> On Sat, May 31, 2014 at 11:42:14AM -0700, Marc Shapiro wrote:
>>> Keeping this on the list...
>>> That's documentation, of a sort. Not great, but it does pretty much
>>> verify that there is nothing in there for handling budget, or future
>>> transactions. Since I would need that in order to do a proper
>> Yes - this is what I found - no access to budget in mainline gnucash
>> (never looked at future transactions)
>> I do have updates to the current bindings (mainly gnucash_core.i)
>> that give access
>> to GncBudget - however some hacks are needed to actually lookup budgets
>> by name which although they work are not the hacks you want in
>> distributed code
More information about the gnucash-devel