Re: libole2


Subject: Re: libole2
From: James Montgomerie (jamie@montgomerie.net)
Date: Thu Mar 30 2000 - 18:21:52 CST


"Paul Rohr" wrote:

> Subject: Re: libole2
> Date: Thu, 30 Mar 2000 15:56:35 -0800
> From: Paul Rohr <paul@abisource.com>
> To: James Montgomerie <jamie@montgomerie.net>,
> Dom Lachowicz <dominicl@seas.upenn.edu>, justin@ukans.edu,
> abiword-dev@abisource.com, cmc@stardivision.de
>
> Ideally, we'd all be able to share a standalone XP libole2 with
minimal
> external dependencies, so that it could be used everywhere:
>
> - in Gnumeric
> - in standalone wv
> - inside AbiWord (via wv)
> - inside AbiCalc, etc.

You make some very good points. It would indeed be bad to make libole
depend on wv or Abi (which was, I admit, kind of what I was suggesting a
few moments ago. I think my mind must be in the process of changing...)

The things that irk me especially are the three implementations of e.g.
unsigned 32-bit integers we'd have if we also imported glib. It's not a
big problem, it just doesn't seem consistent to me.

I've pasted Dom's list of glib dependencies below - my idea is that
tomorrow I'll take a look at WV and see how much of this stuff can be
#defined away to WV things, or taken care of with ultra-simple extra
implementations, without changing the libole2 code, except for adding a
couple of '#include's. I'll put the extra files ('glib-hack.c',
'glib-hack.h'?) in a sub-section of the wv tree, along with the libole
stuff. Done this way, it'll avoid having to port glib now (and will not
make wv dependent on glib), but would avoid adding any major
dependencies to libole and would leave us free to use glib in the
future, if we so wish.

If my task becomes too complicated, however, I'll bow to glib's
supremacy :-)

Jamie -> ...and so to bed. (It's late in the UK...)

    g_return_if_fail, g_return_val_if_fail, g_assert, g_warning, g_error
macros
    GList (doubly linked list)
    gint, guint, gint32, gpointer, etc... typedefs for most standard
types
    GArray
    and g_new, g_new0, g_malloc, g_malloc0, g_free (memory related
macros and
functions)



This archive was generated by hypermail 2b25 : Thu Mar 30 2000 - 18:21:40 CST