From: Jody Goldberg (email@example.com)
Date: Thu Jul 18 2002 - 17:18:20 EDT
On Thu, Jul 18, 2002 at 10:34:09PM +0200, Joaqu?n Cuenca Abela wrote:
> copy & paste also has its advantages, though. I've never *EVER* had a
> problem to install abiword in *ANY* computer. Not matter how old the
> redhat was :) Except when I tried to do it with the gnome version...
> follow my finger: gnome-print & gal.
True, these are both libraries that (for differing reasons) failed.
> But the fact is that sometimes it doesn't pays off: gal brings us two
> buttons in the toolbar
It brings a good deal more than that. However, your comment
highlights why gal failed. In retrospect is unsurprising that people
did not know all the random bits stashed in gal. libgsf is nothing
like that. It has a clear and coherent goal.
> gnome-print a print preview roughly
> equivalent to the abiword main screen zoomed out.
gnome-print failed because it was largely unmaintained. It does, or
is intended to do far more than print preview. Do you want to write
a pdfs directly, deal with font encodings in postscript, handle
print job notification ? These are all things that document style apps
need to do that we should be replicating in every app. Indeed,
despite the pain it has caused me (Most common installation problems 1,2 & 3)
it still seems like a good idea.
> These are the kind of thing that makes an app polished, and Dom did an
> *EXCELLENT* work with them, but sometimes I ask myself if it would be
> better just to copy the code to put the color selector in the toolbar
> from libgal...
Dom's code was rewritten long ago. However, that highlights one of
the issues in cut-n-paste. Code flows 1 way. Dom was able to merge
updates to libole into the abi-local copy. It was only by
happenstance that I noticed abi-weekly-news comments about local
However, you're right we would be better off just copying a single
widget out of gal rather than adding that depend. However, that
logic does not apply to libgsf. It's goal is to provide an io
platform, and a place to share code. If you'd rather not share
things then there is really no point in proceeding.
> I would like to see (at least) a firm intention to not change the
> ABI of the lib for at least 2 years
> > 5) Have any of you looked at the api ?
> not yet, sorry
Excuse me ?
I'll let me track record in Gnumeric speak to the ability to release
responsibly. However, we are definitely _not_ going to freeze the
API to a library that you have not even tried. Will it stabilize at
some point ? Absolutely. However, now is definitely not the time to
This archive was generated by hypermail 2.1.4 : Thu Jul 18 2002 - 17:24:06 EDT