--- Jody Goldberg <[EMAIL PROTECTED]> 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 > comment > 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 helped... > 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 accept. 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 past errors. > > 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 products. 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 some feedback > 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. Cheers, ===== Joaquin Cuenca Abela [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
