Re: GnuCash page on GO site

[Josh Sled <jsled-gnomeoffice asynchronous org>]

On Fri, Feb 20, 2004 at 01:01:21AM +0000, Charles Goodwin wrote:

| Why doesn't the GnuCash team look at what it can draw from GO?  Given

Well, that's part of the goal, here. :)

| 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

Hmm.  Sometimes it's not that easy.  GnuCash, in particular, has a set
of custom widgetry that we can't just "take" from anywhere else ... but
instead needs to be ported to the Gtk2-way.

Your recent post about leveraging Gnumeric's custom widgetry is well taken.
I have a strong feeling that it'd be about the same level of complexity to
factor out the gnumeric widgetry into something usable by gnucash as to port
the gnucash custom-widgetry forward, for the moment.

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

Hmm.  That is indeed valuable.  There's also the aspect of only changing
one thing at a time [i.e., moving the GnuCash codebase, w/o functionality
changes, from Gtk1 to Gtk2] to manage complexity, and limited developer
resources.  But leveraging existing stuff rather than re-writing it is
a valuable effort to undertake, indeed.

I got a feeling from your mail that I'm suggesting that other projects
look to leverage GnuCash in some way -- specifically in (2), below.
I'm not.  I'm suggesting that the most valuable libgoffice library would
include only components that are shared by a majority of libgoffice apps,
and looking at what GnuCash currently does which fits that bill.

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

Hmm.  From a programmer perspective, I think the easiest thing to share
are those things that are already very well-defined, such as mathematical
operations.  The trickiest bit is the numeric representations between
the library-callers, but that's likely resolvable in a constructive way.

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

Word.  We currently use Guppi, and are really hoping to switch to the
"next gen" graphing lib factored from gnumeric.

Good graphing APIs and implementations are one of the harder things to
come by, in the world, however... but, as you say, high-value.

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

Reporting is generally painful; I'd call this one low-prio because of
the complexity and the cost/benefit.

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

Well, I think there are a set of existing standards [calendar-related]
that can provide the basis for a specific implementation [library].
Some of this already exists in glib, but a higher-level library might
also be useful -- hopefully to be folded into glib.

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

[obsessed? how?]

Well, our requirements are _slightly_ different than Gnumeric, I think,
but also the same as a lot of other programs:

* present a non-editable row/column matrix of information [view+controller],
  backed by a data-model.
* allow a range of data [a "cursor", in GnuCash's parlance] to be selected
  for editing.
  * notify the model that a range has been selected/is being manipulated.
  * notify the model that a range has finished editing, with support for
    conflict-detection, resolution.
* utilize various visual/style properties [both color/format and
  display-widgets]

It's basically a CTree or CTable, but with a bit more of a protocol
between the Model and View/Controller, and a higher-level interface for
the developer.  As well, something that could be moved down into GTK
itself over time.  But, as per the point earlier, it might not be the best
near-term goal.

A lot of our users are clammoring for a Gnome2 version, right now.  The
goal is to satisfy that desire first, then improve upon it [through whatever
shared/abstracted widgetage we can develop] later.

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

A shared viewpoint, indeed.

GnuCash is larger than it needs to be, right now.  Some of that is internal
to GNC, but some can also -- hopefully -- be reduced through cooperation
with other projects.

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

Sorry ... I meant "why are these _not_ just part [...]". :)

| -- 
| - Charlie

...jsled

-- 
http://www.asynchronous.org - `a=jsled; b=asynchronous.org; echo ${a} ${b}`