Re: GnuCash page on GO site

On Fri, Feb 20, 2004 at 11:47:28AM -0500, Derek Atkins wrote:
> Jody Goldberg <[email protected]> writes:
> 
> >> 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.
> 
> Getting help porting our existing Guppi calls to the new libgoffice
> plotting would be very useful and helpful to us.

That is a a tad tricky given that the current interfaces are
targeted at what are likely to be non-standard use cases.  I've just
written the first case of code creating a plot from what seems like
a more standard approach (not importing from xls, and not using the
ui).  I added a few more convenience classes and wrappers already.
We'll likely want to add more.
 
> Where is there a released libgoffice I could pull down?
It currently lives in
    gnumeric/src/cut-n-paste/goffice

> We've currently got a "densecal" widget which might be useful to
> push down into libgoffice.  It's got the ability to "show" multiple
> months at a time in a dense format, using color coding to designate
> events and uses a popup "tooltip-like" interface to explain the events.

Sounds neat.
 
> Do you have a phrase-wheel?  :)

What's a phrase wheel ?
 
> >> 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.
> 
> That might be useful...

potentially yes, but I'd like to avoid hyping this at all.  It was
not written as a general purpose rendering abstraction, it just
turned out that way.  I'm going to see if I can convert gnumeric to
use it in place of gnome-print.  If that is possible, it may be
useful elsewhere.  The benefit would be things like
    - png/svg export
    - a simple migration path to cairo's rendering api

> > 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.
> 
> Are there any docs for gsf?  I certainly couldn't find any.

The classes are thoroughly documented in the source with gtk-doc.
There are also a large collection of test cases and real world
usages.  The api is mostly trivial and has definitely helped clean
up alot of code.

> >> 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.
> 
> Why is a "piechart" over the top?
 
To display a piechart one needs a swath of support routines
    - rendering
    - legends
    - titles
    - data abstractions

Anyone can write a cheesy little pie plot in a few lines, but it
will not work in the more general case and does not belong IMO in a
widget library.

> > 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.
> 
> If lots of places need to perform the same second-level operations
> on the basic GDate then I suspect it calls for moving those common
> second-level operations into glib.

Quite possibly.

> > 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.
> 
> Who cares if they are 100% useful in 100% of the cases?

At issue is not 100% of anything.  Gtk is not going to absorb every
random widget.  The widgets in gal were not well matched for gtk and
could not go there.

> They don't
> warrant their own library.  It's one more potentially broken
> dependency for users to complain about without helping developers OR
> users in any way.  If I had a dollar for every time I've had a user
> ask "I ran {redcarpet,up2date,yum,...} and now gnucash wont work" only
> to discover that libgal was updated from libgal.so.19 to
> libgal.so.20....  I'd be a very rich man.

That is more a function of gal sucking.  It was basicly
libevolution, with a bunch of us sort of dragged along the side with
it.

The dependency issue is why I did not put plotting into a distinct
library from the widgets in a distinct library from the the math
etc.  We can merge things somewhat, but not everything can go down
into glib/gtk.