Re: GnuCash page on GO site

[Derek Atkins <warlord MIT EDU>]

Jody Goldberg <jody gnome org> 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.

Where is there a released libgoffice I could pull down?

>> 3/ reporting -- 
> Good idea.
>
>> 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'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.

It's quite cool. :)

>> 5/ widgets -- specifically:
>>    a/ register [or, a generic cell-range editor abstracted which a
>>       financial-account register could be built on]
>>    b/ calendar/frequency manipulation
>>    * could-also-be-used-by: nearly all if the widgets are general purpose
>>      enough.
> Those are more special purpose than what I've been pulling down so
> far.  To date I've been putting in things like
>     - colour combo
>     - pixmap combo
>     - character encoding selectors
>     - The FooCanvas (a simplified non-aa canvas abstraction)

Do you have 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...

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

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

That's not true.  We would still need to convert from the schema to
our objects (and back).  That's true regardless of whether we use gda,
dbi, or odbc.  The amount of work we have is about the same in all
cases.

The fact that none of these db interfaces support NOTIFY is a problem
for us.

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

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

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

-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