Re: GnuCash page on GO site

[Jody Goldberg <jody gnome org>]

On Thu, Feb 19, 2004 at 03:14:55PM -0500, Josh Sled wrote:
> What -- then -- are the common functions which [most] GO apps can leverage?
> 
> From GnuCash' perspective:
> 
> 1/ financial calculation API/implementation -- interest rate computation,

Some of the analytics and numeric support routines in gnumeric will
definitely migrarte down into libgoffice.  Certainly not all of
them, there is no general need for linear programming engines.
However, we could certainly sit down with some gnucash developers
and look into what would be useful.

> 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.

> 3/ reporting -- 
Good idea.

> 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.

> 5/ widgets -- specifically:
>    a/ register [or, a generic cell-range editor abstracted which a
>       financial-account register could be built on]
>    b/ calendar/frequency manipulation
>    * could-also-be-used-by: nearly all if the widgets are general purpose
>      enough.
Those are more special purpose than what I've been pulling down so
far.  To date I've been putting in things like
    - colour combo
    - pixmap combo
    - character encoding selectors
    - The FooCanvas (a simplified non-aa canvas abstraction)

> 6/ printing
>    * probably everything, but is this "office"-specific?
It can probably continue to live in libgnomeprint, although there is
a rendering abstraction in libgoffice so that the charts can render
to screen, printer, or svg using one interface.

> 7/ configuration
>    * there's probably some "office"-specific config [mail server, org
>      structure/roles, &c.] ... but it also seems not necessarily "office"
>      specific.
Things get dicey here.  Things like
    - help browser
    - configuration management (gconf)
    - system config (web browser, email handler ...)
are all tied to the libgnome level and up.  Those libraries are
commonly available, but not portable.  Win32 and osx versions of our
apps will require alternatives.

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.

9/ libgda
    No need to write your own data base access routines.

> Specifically about (4) and (5), and maybe even (2) ...  Derek's point
> is well-taken: why are these just part of gtk or glib if they're that
> general-purpose?

2) a charting engine does not belong in gtk.  That's going well over
   the top.
4) Some of the basic routines could be in glib, but then again, the
   basic routines are already there.  We use them.  A daycount basis
   or parsing a date string 50 different ways may be too domain
   specific for glib.
5) I suspect some of them do belong there, and will migrate some
   day.  The gal widgets didn't go down because they didn't meet the
   quality standards of gtk.  They worked in the simple case, but
   weren't well designed for all possible uses.