Gnucash architecture and dependencies

[Josh Sled]

On Tue, Aug 12, 2003 at 01:31:51AM -0400, Benoit Gr?goire wrote:

| As for the architecture, it's not too bad, and it's actually getting cleaned 
| up as a byproduct of the gnome 2 port.  In an ideal world, we would a fair 
| amount of time to do code refactoring.  But until we do everything I outlined 
| in the article, major organized refactoring (such as reworking dependencies, 
| or major architecture changes) which do not solve an immediate problem are 
| not likely to happen, and likely to do more harm than good in some cases.

No, it's not too bad.  It feels like there's too much build-gunk, however.
And I don't feel like there's super-clean module responsibilities.

Having a good set of tests helps a lot, here, to know when changes haven't
unintentionally or subtly b0rken anything.

| Well, I mentioned in the article that the web site is is out of date and 
| misleading, so I fully agree...

A Wiki would lower the barrier to entry for "random" people [no offense] to
keep things up to date.  This Wiki _MUST_ be on gnucash.org ...  I strongly
recommend TWiki, but any one will do.  But it must be on gnucash.org.

As well, there's a lot of stuff that goes on on #gnucash ... mostly FAQ
stuff due to guile dep-issues that aren't googleable ... that could be
kept there.

| Sincerely, I don't see much to dump.  
| -Technically we could dump XML eventually.  
| -Dumping guile just to replace it with another scripting language is neither 
| realistic nor really usefull.  

An interesting subset of the system is written in guile ... I'm not
necessarily advocating dumping/replacing it, but perhaps alongside,
[insert-more-popular-language]-bindings might be helpful.

Weekend developers would help the project.  Weekend developers transition
into full developers.

Lisp is awesome, but nobody knows it.  People do know Perl and Python.
I'd vote for the latter.  The class of people we need to attract [bug
fixers and small-change-adders seem to know and love it.  It's viable to
write larger projects in, and will be around for a while ... even if it
has an unforgiveable attitude toward whitespace. ;)

| -Dumping g-wrap or alternatively swallowing it's codebase is a good long term 
| goal.  

Swallowing it, it seems ... without some major sub-system re-writes, we
need it for a while.

| -GtkHTML has it's problem, but is absolutely essential for reports.

No ... GtkHTML is lame, and we three features from it: image placement,
basic layout and tables for report output.

We should use Gtk's own layout engine, and ability to put graphics in
the system.  We should be getting graphics from guppi [see below], and
we should use Gtk's own ctable [or gtk2 replacement] for report output.
What's left ... hyperlinking?  We can deal with that.

The reports shouldn't be outputting html, anyways.  Not even xhtml.
Maybe some ad-hoc or other data-graph what can be transformed into html
[or some other ad-hoc/spec'd XML reporting format which can then be
xformed into html+svg or something].

| -Guppi no standalone replacement for this exists, but we are talking with the 
| gnumeric developers to see if we can spinoff their graphing engine.  Rolling 
| our own from scratch would be a monumental waste of time.

This is a serious problem... not only for GnuCash.  Desktop environments
generally need a graphing/viz. service.

| What you say is true.  Unfortunately, most home users can't code, and most of 
| those who do do not see financial software as something sexy to work on.  Our 
| primary "market" has truly always been the home user, and will most likely 
| remain so.  (Let's leave the double entry flames for another day).  

Well, we could make that more true... replacing guile with a more
... accessible ... language and exposing useful data [account access,
transaction creation, form-based GUI creation] ... and making that
pervasive would help.

...jsled

-- 
http://www.asynchronous.org - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
jabber:jsled at jabber.asynchronous.org, ICQ:4983267, {AIM,YIM}:joshsled