Ok, well it is great that someone is attempting to drag that movie player out of sophie. 
Since we must have re-written it 7 times over four years. 

Now I think there are some things consider once one figures out how tweak works, which you are discovering is 
a key part of the puzzle, at least from the viewpoint of how the heck do we go from here to there. 

The concept is that logic is handled a URL  for a media object (video or audio).  It must then determine what type of 
media that is, using features of Quicktime or MimeTypes to figure out a optimal guess at the concrete decoder class to use.
For that a weighted matrix of choices is used because if we have quicktime, use that, but maybe not if it's an OGG movie since
quicktime doesn't support OGG natively, but there is a plugin...  Frankly this is the important piece of the whole architecture.

Next we extract some meta data from the movie (frame size, length, etc) and store in the SophieResourceManager.  That 
helps the visual composing later make decisions about how to place the tweak UI for the playback of the movie.  We do that 
instead of digging into the movie via decoder calls every frame or every time we need to render a place holder for the movie. 
You don't need to drag the SophieResourceManager over, just enable something to store the meta-data.  Hint "how big is the frame of
this movie?" and we don't want to wade thru a million instructions decoding the meta-data to say  640x480... 

Now the decoder logic has a number of goals,  play, stop, rewind, close..  More interesting is play, what happens then is the 
decoder's objective is to start at a particular position in the movie, and on each frame change signal to tweak the frame has changed.
It also has an obligation to keep sane when the use pounds the controls in some frantic set of sense of movement, and the various 
decodes have a bit of hysteria when you attempt to herd them too fast...

So on top of that we have a Tweak UI to provide the UI controls for the play, stop,rewind, head tracking. That of course send cmd requests
to the decoded for the various actions, but it's also listening for the frame did change message.  When it gets that, it then has the responsibility to 
gather up the bits and ask tweak to splash them onto the tweak UI.  Obviously since you are not migrating Tweak into Squeak, then you'll need a morphic replacement for that part of the puzzle.  That part is the least interesting because it' just a shell for forwarding UI actions to the sophie movie model, and ensuring it
paints bits when ask (immediately)...  

BTW lurking in here are two types of timing loops. Relies on the quicktime plugin which has one sole function, that is to signal a semaphore when Quicktime tells us 
the frame has changed, which triggers of course a paint. We only did the plugin for os-x as it's optional.  What other platforms do is setup a timing loop based on the movie frame rate to trigger the frame draw with hopes that it's not too CPU intensive.


On 2010-12-29, at 10:16 AM, Chris Cunnington wrote:

> I do appreciate the truth of that statement. Talking about these things here makes
> me a bit self-conscious, as I like to describe things in historical terms, while all 
> the players are right here. But silence teaches me nothing, so...
> 
> Your site is invaluable to anybody interested in Tweak, which includes anybody 
> who has ever had doubts about Morphic. 
> 
> http://tweakproject.org
> 
> Chris 
> 

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101229/1c9c20b7/attachment.htm