[Gnash-dev] Re: [Gnash-commit] gnash ChangeLog gui/NullGui.cpp

[Martin Guy]

[Moving over from gnash-commit]

2007/7/11, Rob Savoye <address@hidden>:
> Martin Guy wrote:
>
> >  One implication is that boost::date_time becomes a required
> > dependency of Gnash, only for the NullGui. Otherwise it is not
> > required.
>
>   Cygnal also uses boost date time, so we already have the dependency.
> I'd prefer to get rid of all uses of tu_timer.

If you build cygnal. Gnash the swf player still doesn't need
date_time, and implementing the Date class using the date_time
primitives is less easy; Flashplayer uses a double internally to store
seconds-since-epoch, and now so do we.
The operations thye Date class needs are to set individual month/hour
etc fields,which is fairly strightforward to map onto the POSIX time
structure: split it out, change a field and convert it back.
date_time has its own types for time instants as absolute times,
printable times as localtime/DST objects, time intervals and
timezones. Mapping Date's fairly simplistic scheme onto these more
coherent and well-thought-out primitives is actually quite hard.
They're much better if you're writing new code that can inherit their
coherent world-view, but more difficult to use for what the flash
movie player needs.

So unless we reimplement date.cpp the hard way to get rid of ftime,
gettimeofday and their allies, we're still stuck with the old-school
time/date code anyway, which defeats the point of using the boost
version - you just end up with yet another different way of doing time
inside Gnash.

On a separate issue, might it be more appropriate to maintain cygnal
as a separate program (cvs co cygnal from the gnash repository) rather
than bundling it with the flash player? It's not as if they have much
code in common except for the configuration, most of which is
irrelevant to cygnal. I think that would make maintenance and
development of both programs easier in the long run.
 If they do share base libraries (sorry, I haven't looked) that would
also encourage us to separate those code components off as an actual
library with a well defined interface

  M