From: Joaquín Cuenca Abela (cuenca@pacaterie.u-psud.fr)
Date: Thu Jul 18 2002 - 16:34:09 EDT
On Thu, 2002-07-18 at 20:03, Jody Goldberg wrote:
> I've just caught up with the followup traffic on the initial post
> and would like to add a few thoughts.
>
> 1) Please do not attempt to cut-n-paste the library and rip out the
> glib depend. This is not as simple as it was with libole2, we
> do actually use gobject now. I've specificly tried to respect
> the needs of the abi-dev team when I wrote the library. The goal
> is to provide a _shared_ library for our projects to put common
> functionality. That is not going to happen if you fork it.
Jody, I understand your objections to each project doing a copy & paste
of libgsf. You finish having size bloat, syncing libs becomes hard,
world domination takes longer to accomplish, etc, etc, etc
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.
We've grow (here I'm considering "we" as the GNOME project) to say our
users something as "if you try to install that, you'd better check you
have libs no older than 1 month (even that sometimes is too older)"
Why? because we're cool and beta and you should expect these little
annoyances, because we're share much code and that's good, etc.
But the fact is that sometimes it doesn't pays off: gal brings us two
buttons in the toolbar and gnome-print a print preview roughly
equivalent to the abiword main screen zoomed out.
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...
Coming back to libgsf. We *MUST* copy it and ship a copy with abiword
at least in non linux platforms. Windows users are already asking us
why, oh why they have to download abiword and a spell dictionary
individually (point that becomes clear when you update your abiword copy
usually).
I don't think that they're going to understand a: "you should download
it because there is another app in the world in another OS (that you
don't even known about) that uses it."
If we're going to copy & paste (read: shipping an internal copy with
abiword) in linux is another issue. I would like to see (at least) a
firm intention to not change the ABI of the lib for at least 2 years
(since we start using them in usable copies of abiword, which doesn't
means 1.1, but neither 1.2). I should be looking like an absolute
asshole, saying you how do you have to manage your lib and your work.
Please take it only like a constructive criticism (of something that
you've yet not done :). That's REALLY important if we're going to
depend of this lib, and if we want users upgrading his copy of gnumeric
without screwing his copy of abiword, or dia, or whatever.
Really, that should not be a libgal like lib.
> 2) GLib has been ported to win32 and most other platforms. You
> need not depend on it publicly, but it makes life much easier for
> those of us writing in C.
/me retains a ++comment :)
> 3) Build system pain. This is always an irritation. I had not
> though about this. There are lots of potential solutions.
> - Have the abi-make people add the appropriate gunk to libgsf
> and force libgsf to depend on abiword on the platforms you
> support
I don't think that it would be necessary. If you're using autoconf and
you don't mind, just change your Makefile.am to GNUMakefile.am. We'll
have to write a classic Makefile system but that's all.
You don't have to put a dependency on AbiWord, and both systems can
coexist together (but I *hate* doing .
> 4) libxml2 depends. Yes, this could currently be removed. Those
> are just convenience routines. My longer term goal will be to
> move many of the convenience routines here from gnumeric.
> - load/store colours
> - DOM tree child by name
> - SAX state nodes and support
> ...
> All the useful little tidbits we've accumulated. It would be
> nice to share them.
>
> 5) Have any of you looked at the api ? I'm specificly interested in
not yet, sorry
> the C++ perspective here. Do you folk use iostreams as your
> i/o abstraction ?
Nope.
Cheers,
-- Joaquín Cuenca Abela cuenca@pacaterie.u-psud.fr
This archive was generated by hypermail 2.1.4 : Thu Jul 18 2002 - 16:39:03 EDT