Re: libgsf

From: Joaquín Cuenca Abela (
Date: Thu Jul 18 2002 - 16:34:09 EDT

  • Next message: Jody Goldberg: "Re: libgsf"

    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

    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 to 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 ?



    Joaquín Cuenca Abela

    This archive was generated by hypermail 2.1.4 : Thu Jul 18 2002 - 16:39:03 EDT