From: Jody Goldberg (jody@gnome.org)
Date: Tue Nov 19 2002 - 20:22:56 EST
On Tue, Nov 19, 2002 at 04:35:19PM -0800, Dom Lachowicz wrote:
> > > 1) 1 Class to handle the META-INF/manifest.xml
> > > 2) 1 Class to handle Pictures/*
> > > 3) 1 Class to handle settings.xml
> > > 4) 1 Class to handle meta.xml
>
> > Can any of 1-4 be done in libgsf so that I can use
> > it too ?
>
> In some cases, this might honestly be more work than
> it's worth.
>
> For #3, I'm just going to dump a standard settings
> file out, since we don't do anything interesting with
> that file. For MetaData, I can do *some* work inside
> of libgsf, but it's a bit more work than that. We'll
> see how this goes. #1 should be possible inside of
> libgsf, seeing that it's mainly just a ls_R, excluding
> anything named "META-INF". #2 isn't worth pushing up,
> probably.
>
> I'll build these things inside of AbiWord first, and
> then we'll evaluate whether they should be pushed up
> to gsf or not. k?
Sounds fine, prototype and design wherever it is comfortable. We've
had the 'lets share the workload' talk enough times that everyone
should be pretty clear on our views.
1) An gsf-openoffice-utils routine to add that would seem to be a
pretty good fit. It is tempting to subclass a GsfOutfileOOffice
from GsfOutfileZip and have it tack the manifest on.
2) Agreed. Although if we can ever start work on a shared embedded
object and drawing this would be the place to start it.
3) Ok. When I did the parser for this in gnumeric I had plans to
add a generator too. Since I need this more than you I'll do the
work. You can then just fill a settings blob with constant
values rather than hard coding content. Then we can handle
format changes centrally.
4) This obviously depends on out getting the DocMetadata stuff
whipped into shape that has been on hold.
This archive was generated by hypermail 2.1.4 : Tue Nov 19 2002 - 20:24:30 EST