Re: Making Conglomerate part of Gnome Office

[Jody Goldberg <jody gnome org>]

On Thu, Sep 18, 2003 at 01:01:34PM +1000, Martin Sevior wrote:
> Those are nice! AbiWord has something similar already for the last one.
> But this does raise the issue of libgoffice for shared stuff which was
> something we planned to look at post GNOME-Office-1.0. There are various
> bits I'd like to see from Gnumeric in there (the code for shading cells
> in particular). AbiWord has an uber cool insert table widget which might
> be useful for Conglomerate, Mergeant and Evolution. Plus Dom will
> shortly start on his generic grammar/auto-completion/auto-correction
> framework which would useful to Conglomerate.
> 
> GTK-MathView have also just announced a MATHML bonobo widget which would
> be useful to AbiWord and maybe Conglomerate.
> 
> I guess we should look at putting this library together somehow.

It will probably take until the end of the month for the dust to
settle on Gnumeric'a 1.2.x tree before we branch.  As soon as that
happens the first order of bussiness will be pulling out the nascent
library and as much of gnumeric's inards as it requires.

The gnome-office list seems like the best place to discuss its
development, so I'll keep people apprised.

To date I've kept the depends small
    1) glib
    2) libxml
    3) libgsf
    4) gtk
	1-3 shouldn't be controversial.  The last we'll need to
	discuss as it may make things difficult for abi's
	X-platformness.

	Its feasible to pull the support widgets into a distinct
	blob (ala libgsf-gnome) but it adds quite a bit to the
	complexity.  Of course it would be possible to just use this
	in the gnome or gtk versions of abi, but that seems like a
	questionable use of resources.  Dunno, we'll need input from
	abi-folk on where this line needs to live.

The charting elements add 3 more
    5) pango
	This doesn't drag too much with it and has huge potential.
	Its not as bad as gtk, but still iffy in abi-land.

    6) libart
	This is lightweight, and portable, but largely unmaintained.
	librsvg uses it.  Its a debatable requirement that will
	depend alot on the utility of cairo.

    7) gnomeprint
	This one is shaping up to be _the_ piece of the gnome office
	platformat that needs love.  Its effectively unmaintained.
	Its api is not optimal, and we all need it.

    I've currently got a rough and ready rendering abstraction in
    the charting engine that I'm using to isolate the code from
    direct interaction with libart and gnomeprint.  I've been
    tempted to use that as a printing interface for gnumeric itself,
    so that changing to a cairo later will be less work.