Re: GnuCash page on GO site

[Jody Goldberg <jody gnome org>]

On Sun, Feb 22, 2004 at 09:29:20PM -0600, Linas Vepstas wrote:
> On Fri, Feb 20, 2004 at 11:26:38AM -0500, Jody Goldberg was heard to remark:
> > 
> > > 2/ graphing -- visual reporting, {line,bar}-charts, pie-graphs,
> > This is the core of libgoffice right now.  The library is pulling in
> > all pieces necessry to display/print/export plots.
> 
> Gnucash desperately needs better graphing infrastructure.
 
Then you're in luck.  I've been reaonsably happy with the new
variant in libgoffice.  Now that I've got some implementation
experience in there, it feels like this is a step in the right
direction.

> > > 4/ time-handling -- date/time format, time computation, recurrent-events
> > The formating and parsing are getting pulled from gnumeric for the
> > charting engine, and we can certainly add some of the date math
> > utilities.  Indeed it would likely be useful to include our library
> > of financial date math (daycount basis) and potentially calendars.
> 
> We use GDate now, and an assortment of other bits and pieces that 
> GDate doesn't have yet.  Its sort-of messy, this is some of the very
> oldest code... I don't think this stuff is high tech.
 
Agreed.  At best I see this as merging some utils.  No major
architecture shifts.

> > I'll add an 8 and a 9
> > 8/ libgsf 
> >     A nice clean i/o abstraction.  It makes it much easier to handle
> >     clipboards, correctly handle corner cases on the local file
> >     system, and remote files.
> 
> does the cliboard handle complex objects? e.g. we need to cut-n-paste
> a transaction, which is a collection of a date, some numeric values, 
> a memo, some pointers to accounts, etc...

Wrong level of abstraction.  The core of gsf is a stream interface
read/write.  You can pump whatever data you want into that.  The
benefit is the simple comfortable interface that will go to or from
    - files
    - memory buffers
    - mmap
    - gzip/bzip content
    - vfs/bonobo (with the optional libgsf-gnome)
The other main abstraction is the structured file interface with
implementations for zip, ole2 (possibly tar if I bother to finish
it).  I suspect you just want to pump over some xml.  No need for a
zip file of fields.  Although there are some cute little libxml
convenience routines to make writing fast sax based parsers and
exporters (including namespaces) easy.


> A better overview of gal would be nice.

Just call it 'libevolution' and ignore it.

The intent was to be something similar to libgoffice.  Unfortunately
it was tied rather strongly to evolutions release needs and never
really servered the general population.