[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: [Gnash] Playing multiple movies at the same time
From: |
strk |
Subject: |
Re: [Gnash-dev] Re: [Gnash] Playing multiple movies at the same time |
Date: |
Mon, 20 Aug 2007 19:22:38 +0200 |
On Mon, Aug 20, 2007 at 07:17:50PM +0200, Sergio Garcia Murillo wrote:
> I don't like the idea of the singleton at all, but I don't want to start a
> flame war, and it's
> easy (and stupid) to criticise something when you have just take a look at a
> few files :)
There were only globals initially, the singleton was an intermediate step
toward the task you assigned to yourself (for which we tank you).
> The only use (rigth now) for the VM is storing the movie and the garbage
> collector.
And the Stage, and drive version-specific behaviour.
> For that use you don't need a singleton and it doesn't matter if you create
> an object at
> the begginng or create one when you call init, as all it does is just store
> the pointers.
I wasn't discussing implementation, just interface.
The gnash team is pretty large and eterogeneous, so I prefer compile-time errors
or easy to get assertion failures then obscure bugs.
> I think we should redisgn the whole idea of the vm (more on this later).
Ready for discussing proposal.
> > I guess every *run* (movie) would need:
> > - A VM (which would have a GC)
> > - A base url
> > - A render handler
> > - A sound handler
> >
> > You might encode these 4 members into a context class (Application?).
>
> Yes, I was thinking in doing something like that, use the VM just as a
> factory.
> We'll have a singleton of it and it will just load the default configuration
> parameters
> for all movies and even log files, debugs, etc.. and create instances of the
> "application context".
Could you explain this further ?
In my vision we'd have a VM for each application (ie: first-loaded movie)
as that'd drive version-specific behaviours.
> It's just the first move, the hardest work is going to be appending
> references to the
> app_context (pr the relevant object) in every place that is needed.
What about working on definition of the ApplicationContext class first ?
--strk;