From: Jody Goldberg (email@example.com)
Date: Sun Oct 26 2003 - 22:36:41 EST
On Sun, Oct 26, 2003 at 03:49:26PM -0600, Michael D. Pritchett wrote:
> On Sun, 26 Oct 2003 firstname.lastname@example.org wrote:
> > For developers on other platfroms, I believe the plan is for all platforms
> > to have this capability, not just GNOME. libgsf is highly portable and
> > employs portable libraries like glib, zlib etc.
> > If you don't want your platform to have libgsf capability please send an
> > email and complain and be specific in your reasons.
> > Cheers
> > Martin
> Not that it matters, but I don't want this for Win32.
I'd be very interested to hear why. libgsf was created specificly
to provide a shareable cross platform library that Gnumeric and
abi could both use. Something akin to the xp_* layer in abi, in a
form that Gnumeric could digest too. Admittedly that is a bit of a
pill for abi-folk to swallow, so I've done a significant amount of
work to ensure there is lots of sugar to help it go down. Even if
you ignore the benefits of a larger user and maintenance base for
the library (rather than rolling your own in abi) there are benefits
- better OLE2 than MS in several areas (eg exporting block sizes
other than 4k)
- A nice fast collection of libxml wrappers that make SAX
input/output parsers much easier to maintain.
- The benefit of a coherent interface to several different forms
of i/o. Something that has gone through the rigours of
testing for an app of similar scope/complexity as abi.
Once libgsf is indeed shared. There are huge potential benefits.
Most notably, we can start actively sharing code between our
1) OO import/export support code. Why should we waste precious
resources duplicating this ?
3) A structured file format for embedding Gnumeric content in abi or
As an experienced win32 abi-developer it would be great to get your
ideas on how to wrap native win32 capabilities rather than using
a cross platform lib like libcurl. In a gnome environment we're
better off using gnome-vfs, in KDE kio, in win32 or OSX we'll want
something else. The goal as always is to make the app blend into
its environment while providing developers with a uniform interface
so that we don't have to think about it more than once.
This archive was generated by hypermail 2.1.4 : Sun Oct 26 2003 - 22:38:06 EST