From: Kenneth J. Davis (jeremyd@computer.org)
Date: Sun Oct 26 2003 - 13:28:00 EST
On Sat, 25 Oct 2003 21:54:28 -0700 (PDT) Dom Lachowicz <domlachowicz@yahoo.com> wrote:
DL> > For developers on other platfroms, I believe the
DL> > plan is for all platforms
DL> > to have this capability, not just GNOME. libgsf is
DL> > highly portable and
DL> > employs portable libraries like glib, zlib etc.
DL> >
DL> > If you don't want your platform to have libgsf
DL> > capability please send an
DL> > email and complain and be specific in your reasons.
DL>
DL> Yeah, eventually I want to make all our platforms use
DL> libgsf.
DL>
DL> First, I want to create a separate branch from HEAD so
DL> that we can work on the gsf stuff in there. Once all
DL> of our importers/exporters are ported over to use GSF
DL> and once we get the various build systems working
DL> properly, we can re-merge the branch with HEAD.
DL>
DL> I'm thinking slow-and-steady here - probably this'll
DL> take a month or two along with a bunch of planning and
DL> coordination on everyone's part.
DL>
DL> Thanks,
DL> Dom
DL>
Ignoring my bias against glib/etc on Windows, please do this
in Head, I don't think my mind can handle another branch and
if we are going to add this set of dependencies, then I want
to go ahead and work on cleaning out/up* duplicated work
(xml parser, iconv, ut_*, ...); switch the Windows build
over to enchant, and alter the glib/gsf based plugins to
no longer include glib/gsf/etc. (I'll try to commit their
installer later today, after I get a chance to check/fix
any build issues on Windows with them.) Also, are we going to
build glib/gsf like we build the rest of our libraries or are they
going to be binary additions to our build process? Does
a Win32 developer need to talk with the Gimp for Win32 folks
so we can share their glib implementation and coordinate any
fixes necessary with them? Are we going to use their binaries?
or just their source? is their glib/gtk/etc source the same as
the Unix based one?
*by out/up, I mean remove any duplicated stuff in our tree that
can be replaced either by glib or by one of glib's dependencies
and switch several of our static libraries over to their dll
variants. My only technical objection to glib is the duplicate
functionality; though I dislike the gnome/glib style and of
course am a KDE not Gnome person.
:-)
Jeremy
This archive was generated by hypermail 2.1.4 : Sun Oct 26 2003 - 13:29:38 EST