GnuCash page on GO site

Martin Sevior msevior at seviorpc.ph.unimelb.edu.au
Thu Feb 26 00:49:53 CST 2004


On Thu, 2004-02-26 at 16:13, Linas Vepstas wrote:
> On Mon, Feb 23, 2004 at 10:13:17PM +1100, msevior at physics.unimelb.edu.au was heard to remark:
> > >> > > 3/ reporting --
> > >> > Good idea.
> > >>
> > >> Note that reports mean different things to different people, and
> > >> that as a technology, its a *HUGE* bundle of requirements.
> > >
> > > Perhaps it is worth formally documenting them somewhere.  From your
> > > descriptions (template-editable-in-word-processor and
> > > database-fields-pulled-together) I don't see any reason it cannot be
> > > accomplished well.  I might even help code to such a project.
> > >
> > 
> > AbiWord certainly has the capability to do all this right now. 
> 
> I like that; one plan was to use the edit abilites in gtkhtml3 but
> that's not as nice as a "real" word processor, at least for printing.
> For reports that are meant to be web pages, then ... ?
> 

Just export your AbiWord doc to (X)HTML. The HTML exporter is very good
now.

Also since we will use libGSF the reports can be directly exported to
webDav enabled sites.

There are 3 ways you might want to use Abi in gnuCash. 

1. Just start up a standard AbiWord process and rely on the user to do
what they'd like with the report.

2. Embed our abiwidget in your application. Requires linking against the
full Abiword tree.

3. Embed the AbiWord bonobo control in your app.


> > I can show
> > you how to construct documents that use libgda to pull in content from
> > whatever data source you want for programmable fields laid out in tables.
> 
> My gut feel is that libgda offers the wrong abstractions. 
> Although gnucash data can be (is) represented as SQL, that's 
> the wrong place to work.  There's a lot of pulling things together
> that must happen before the data is reportable.  For example,
> computing account balances can be quite complicated; its not a
> simple sql query or a simple table lookup.
> 

This is not insurmountable. We can use our mail-merge fields or even
invent some new ones for gnuCash

Or if the document is static simply paste the results straight into it.

> I started work on "qof" (qof.sourceforge.net) to deal with this.
> I did not get any buy-in from the gda folks on this, though.
> 
> > Doing this in AbiWord has the extra benefit that users can fiddle with it
> > afterward, export them to lots of different formats, cut and paste them
> > into other documents, etc etc.
> 
> Yes, that is exactly what is wanted.  
> 
> Note, another requirement would be the ability to run the reports
> as a batch job, or as a cgi-bin. But this is for the future, no for 
> short term.  Something to think about.
> 

No problem either. AbiWord has a command-line interface and be run as a
document server. I wrote a nice little bit of code that can shows how
this works. See attachments.


> > I actually have a much smaller requirement for my own home-grown little
> > accounts/budgeting program. I'll use AbiWord to show how far each budget
> > catergory is ahead or behind it's projected value.
> 
> One project I'd like to see happen someday is a 'gnucash-simple'
> which would just go back to a very very very simple UI. 
> But that's another day.
> 

I need it now and am discovering the joys of python with libglade :-)

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConvertToText.c
Type: text/x-c
Size: 7031 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040226/3919f353/ConvertToText.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConvertToText.h
Type: text/x-c-header
Size: 1068 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040226/3919f353/ConvertToText-0001.bin


More information about the gnucash-devel mailing list