From: Joaquin Cuenca Abela (firstname.lastname@example.org)
Date: Fri Jul 19 2002 - 07:04:33 EDT
--- Jody Goldberg <email@example.com> wrote:
> On Thu, Jul 18, 2002 at 10:34:09PM +0200, Joaqu?n
> Cuenca Abela wrote:
> > 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.
gal bring *US* two buttons in the toolbar. I was not
stating that libgal was only composed by two widgets.
Their Tree was also nice, and it has some nice things.
But we had this dependency for these two buttons, nor
for the tree or anything else
> However, your
> highlights why gal failed. In retrospect is
> unsurprising that people
> did not know all the random bits stashed in gal.
Changing the so name each couple of months also
> 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.
It *is* a good idea.
That's a good deal of code that *should* be shared,
but, again, you should provide a good implementation
and maintain compatibility to make it work.
A half-done implementation -- lack of font subsetting,
the long time that it took to implement truetype
support, and even with that, last time I checked (it
was not long ago) it was crashing with pretty simple
documents with TT fonts --, and changes to the ABI
every since and then is more than what we should
Now, if Chema fixes all that cruft, I will double
check that he drinks all the beer that I'm going to
pay him at the next GUADEC, and I will be more than
happy to deprecate our ps generator by gnome-print.
> 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'm almost 100% convinced that things will work and
that we're going to share libgsf. I'll not ask for
unreasonable/undoable things, and I'm sure nobody is
going to do it.
I just want to check that we'll try our best to avoid
> > 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'm not speaking about the current api. I'm asking
for firm intention to get a good and long freeze
*once* we're all happy with the lib, the lib is
finished, and we're ready to deploy it with our
Probably that will mean in time for AbiWord 2 (and
that's for more than a few months away), except if
people want to change our file format for AbiWord 1.2.
You really have to speak with Dom and Martin about
these long time plans :)
Even if we don't use it until Abi2, I would like (of
course) to see it in AbiWord to fix any possible
problems asap (activable with an --enable-gsf that
will be disabled by default, for instance), and give
> 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
> do it.
Of course. Excuse me if I was not clear enough. I'm
asking for a freeze basically since we start deploying
it to our users in a product that we label as STABLE.
Joaquin Cuenca Abela
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
This archive was generated by hypermail 2.1.4 : Fri Jul 19 2002 - 07:10:32 EDT