Re: GnuCash page on GO site



What intrigues me is that there are so many facets to GnuCash that
really overlap with other GO applications.  Given the explicitly stated
problems with the GnuCash project (I refer to the 'state of the project'
emails from last year) especially with resources and moving from Gtk1 to
Gtk2, my codebase-ignorant observation is:

Why doesn't the GnuCash team look at what it can draw from GO?  Given
that GO is all Gtk2 already, this would surely also offer a way in which
GnuCash could solve a lot of it's resource problems by offloading
development aspects to the shoulders of others that are already carrying
them anyway!  If there is a project for handling something that GnuCash
needs, then why not look at incorporating it in the Gtk2 rewrite rather
than porting it from the Gtk1 GnuCash?

I'll give examples inline:

On Thu, 2004-02-19 at 20:14, Josh Sled wrote:
> From GnuCash perspective:
> 
> 1/ financial calculation API/implementation -- interest rate computation,
>    &c.
>    * could-also-be-used-by: gnumeric, [gnome-db?]

I think there's definitely scope for the sharing of statistical analysis
issues between the two, although it's probably unrealistic at this
juncture given the most likely particular implementations of Gnumeric vs
GnuCash: they probably work in very different ways.

> 2/ graphing -- visual reporting, {line,bar}-charts, pie-graphs, of
>    temporal/account/funds-movement behavior.
>    * could-also-be-used-by: mr project, toutdoux, gnumeric, gnome-db, abi-word

This is definitely an area where GnuCash should be looking to leverage
Gnumeric's charting capabilities and not the other way around.  I'm sure
that Jody has long planned exporting the charting engine as a library,
and this would probably be an ideal starting point for the two projects
to officially collaborate and develop a world-class charting library.

> 3/ reporting -- I'd be happy if at least the front-end of gnucash reporting
>    could leverage a library, such that gnucash didn't have to implemnt
>    a report-generation sub-program. GnuCash could instead focus on
>    application-specific data-transformations into that generic reporting
>    framework.
>    * could-also-be-used-by: mr project, toutdoux, gnumeric, gnome-db

Reporting is definitely a grey area for GO currently.  I do not know to
what degree a Gnumeric/Gnome-DB combination or planned Mergeant features
can cover for this.  There is Agata [1], but that's Gtk-php (!?).

> 4/ time-handling -- date/time format, time computation, recurrent-events

Evolution is sadly not a part of GO but aiming itself at only Gnome. 
I'm not sure what the consequences are but I'm unaware of any plans to
export Evolution functionality (scheduling-oriented or otherwise) to an
external library that will be of any use outside of Gnome.

> 5/ widgets -- specifically:
>    a/ register [or, a generic cell-range editor abstracted which a
>       financial-account register could be built on]

My sentiments exactly; I always think of GnuCash and how it could be
using Gnumeric-widgets whenever I'm using Gnumeric.  (Holy bejeez I
think I might becoming obsessed?)

> 6/ printing
>    * probably everything, but is this "office"-specific?

GO already has a portable printing solution in GnomePrint.

And this is my ignorant overview as a non-developer.  There are many,
many aspects of GO that will surely be of interest to the GnuCash
project and I would dearly love to see GnuCash become part of GO.

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

Um, they're not 'just part of gtk or glib', are they?

[1] http://www.agata.org.br/
-- 
- Charlie

The future of the net - www.xwt.org

Charles Goodwin <charlie xwt org>
  Member of the XWT Foundation




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]