gnash-dev
[Top][All Lists]
Advanced

[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;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]