Re: GnuCash page on GO site



On Fri, Feb 20, 2004 at 11:26:38AM -0500, Jody Goldberg was heard to remark:
> 
> > 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.

Gnucash desperately needs better graphing infrastructure.

> > 3/ reporting -- 
> Good idea.

Note that reports mean different things to different people, and
that as a technology, its a *HUGE* bundle of requirements.  

For example: to some people, a "report" is something with the 
correct company logo on top, and the correct margin sizes and 
indents and layout, and the report template can be edited in 
thier word processor.

For other people, a 'report' is a collection of database fields
that are pulled together using a specific set of database queries,
which includes a query editor that a nion-programmer, 'power user'
can edit and set up.  

It'd be great, but don't underestimate the complexity ... 

> > 4/ time-handling -- date/time format, time computation, recurrent-events
> The formating and parsing are getting pulled from gnumeric for the
> charting engine, and we can certainly add some of the date math
> utilities.  Indeed it would likely be useful to include our library
> of financial date math (daycount basis) and potentially calendars.

We use GDate now, and an assortment of other bits and pieces that 
GDate doesn't have yet.  Its sort-of messy, this is some of the very
oldest code... I don't think this stuff is high tech.

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

does the cliboard handle complex objects? e.g. we need to cut-n-paste
a transaction, which is a collection of a date, some numeric values, 
a memo, some pointers to accounts, etc...

> 9/ libgda
>     No need to write your own data base access routines.

I willl try to put this politely but I beleive that libgda and 
gnomedb really have the wrong abstraction of what a database is
or how one codes with one.  I have other ideas, implemented mostly at
http://qof.sourceforge.net/ but its only gotten to 0.2 or something
like that.

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

A better overview of gal would be nice. Every now and then I try to 
figure out if it has something good in it that we might want to use, 
but can't every really figure out 'what its good for' (at least, I'm
not patient enough to ... )

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas linas org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933



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