Scripting

Yawar Amin yawar.amin at gmail.com
Sun Nov 13 10:39:35 EST 2011


Hi Hendrik,

I think the wiki is the best place to start. For example I've been compiling a Scheme API reference on my user page: http://wiki.gnucash.org/wiki/User:Yawaramin

You can also easily create a dedicated page once you sign up for a wiki account there.

Btw, the Scheme bindings do more than generate reports. My impression is you can use them to make GnuCash do pretty much anything.

Regards,

Yawar


Hendrik Boom <hendrik at topoi.pooq.com> wrote:

>On Sat, 12 Nov 2011 12:55:08 -0500, Derek Atkins wrote:
>
>> Hi,
>> 
>> Hendrik Boom <hendrik at topoi.pooq.com> writes:
>> 
>> [snip]
>>> (1) The bulk of the code for gnucash should be a shared library, whose
>>> API (s) provide all the essential functionality of gnucash.  This would
>>> include code for starting up gnucash, shutting it down, reading gnucash
>>> fies, opeining the usual gnucash window, and so forth.  The current
>>> work of converting ad-hoc code to use Gobjects could go a long way to
>>> making this API consistent.
>>>
>>> (2) The gnucash main program itself should operate entirely by using
>>> this library's API.
>>>
>>> Maybe (1) and (2) is how gnucash is already structured; I don't know.
>> 
>> This is already the case..  However it's not a single Shared Library.
>> It's a ton of shared libraries.
>
>Good.
>
>> 
>>> (3) This library would be the basis for scripting interfaces to
>>> gnucash. The API would make the gnucash library itself indifferent to
>>> the scripting language being used.  Of course, the API must still be
>>> clearly documented, or it will be practically useless.  Documentation
>>> in the header files may suffice.
>> 
>> This is also the case.  The Scheme and Python bindings are based on the
>> C APIs by wrapping using SWIG.
>
>Good.  By the Scheme bindings do you mean the hooks for the report-
>generating guile code?
>
>> 
>> [snip]
>> 
>>> But now I'm getting far in advance of myself.  I'm currently arguing
>>> only for a clear, conprehensive, documented API that others could use
>>> to build their own edifices on top of gnucash.  That would open the
>>> gates to all kinds of unexpected collaborations.
>> 
>> I agree wholeheartedly.  Are you willing to help document the APIs that
>> exist?
>
>Yes, in principle.
>
>I hadn't known about the python bindings.  First, it would make sense for 
>me to try to use the python bindings to see if I can do what I need, 
>writing a kind of a diary of what I discover I need to know and producing 
>bits of preliminary documentation as I go.  How does collaboration work 
>with documentation?  Is it a wiki?  or svn access?  or something else?
>
>-- hendrik
>
>_______________________________________________
>gnucash-devel mailing list
>gnucash-devel at gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel



More information about the gnucash-devel mailing list