Re: GnuCash page on GO site

[Derek Atkins <warlord MIT EDU>]

Charles Goodwin <charlie xwt org> writes:

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

As I mentioned, the issue is the ton of gnucash-specific widgets,
displaying lists and trees of gnucash objects necessarily requires
writing the gtk_tree_model and gtk_tree_view code for those objects.

There are very few general-case widgets in gnucash that could be
leveraged.

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

A library of functions would be useful.  I think in the past we stole
it because we didn't want to depend on -lgnumeric..  I still feel this
is a reasonable choice of copy-and-paste unless and until this library
is standalone.

C.f. my statement about adding dependencies.  "gnumeric" is not a
reasonable dependency IMHO.  (OTOH a "libgoffice" would be
acceptable).

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

Gnucash was using Guppi before.  Guppi doesn't exist in g2, so we need
another route.  A shared library would be very useful, but show me one
on RHL9 or FC1?  Those are the 'target platform' that we've chosen at
this point, and we want to require users of those OSes to download as
few additional dependencies as possible.

>> 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 (!?).

Basically, GnuCash has a scheme engine that combines style sheets
and markup tagging in scheme which can then be "processed" into HTML
and displayed using GtkHtml.

I think using HTML as the reporting display is a fine choice...
I'm not convinced that requiring reports to be written in scheme
is as reasonable a choice, but that was done long before I got into
the project.

I'll note that reports also tie into the guppi work.

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

I've got little to say on this topic.

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

Yes, I think you are. ;)

Seriously, we already have a fairly abstracted register toolkit.  It's
even mostly it's own set of libraries (two libraries to be exact, a
base ui-independent library and a gnome-impl).  I think pulling that
out so someone else could use and expand upon it would be an excellent
idea, provided the API was cleaned up a bit.  Any volunteers?

Then we could add a specific equation-editor cell type...

>> 6/ printing
>>    * probably everything, but is this "office"-specific?
>
> GO already has a portable printing solution in GnomePrint.

I have no idea why Josh included this.  We just use GnomePrint
as well...

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

See, we have WAY too many non-developers..  WAY WAY WAY too many..
We've got ideas, bug reports, and enhancement requests out the wazoo,
but not enough developer time to actually implement them..  The LAST
thing we need right now is more ideas.

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

I think josh meant, "why AREN'T these just part of gtk or glib".

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord MIT EDU                        PGP key available