Re: [Laszlo-dev] Text for release notes re: sprites and resource loading (revised)

[Phillip George Apley]

You're right. There's already some ambiguity in distinguishing  
animations from multi-frame resources. For example in examples/ 
animation/animation.lzx, there's a flash movie (swf) of an animated  
logo that displays in a window. The window itself gets moved around  
via animate, but the animated logo is a multi-frame resource, and  
that being in the same example leads one to conflate the two  
concepts. Perhaps this needs to be clarified.

In any case I'll resubmit respecting the distinction.

On Mar 17, 2007, at 4:06 PM, David Temkin wrote:

Not animated views. That's something else.

Views with multi-frame resources is I believe how they are referred  
to in the docs.

On Mar 17, 2007, at 12:29 PM, Phillip George Apley wrote:

Understood. 'animated views' is an adequate phrase.

On Mar 17, 2007, at 1:17 PM, Jim Grandy wrote:

I agree with Tucker. 'Sprite' is an implementation detail, and  
will only encourage people to talk directly to the kernel APIs.  
Given that we expect to continue modifying the kernel APIs --  
they aren't at 1.0 status -- this would be a very bad thing.

jim

On Mar 17, 2007, at 8:50 AM, P T Withington wrote:

On 2007-03-17, at 09:27 EDT, Phillip George Apley wrote:

Tucker,

Since we don't have a concise way to say 'views with animated  
resources', except to say 'sprites' I
wonder if making it more readable by leaving sprites in  
parenthesis isn't justifiable.

I disagree.  Sprite is the implementation behind all views,  
animated or not -- a view is not a sprite, a view has a sprite.   
To equate view and sprite is incorrect.  Further, sprite is an  
implementation element and we should not be talking about it at  
all at the LZX API.  Only LZX implementors need to know about  
sprites.

I think it should suffice to say that events associated with  
animated resources are untested in DHTML.

Edited text below:

Test script for events coming shortly.
-------------------
Issues regarding resource loading and views with animated  
resources (sprites) and behavior in
DHTML and Flash (SWF7, SWF8).

Resource Loading:

There are several ways of resolving resource paths for multi-frame
resources. They correspond to the following path examples:

	1. <view id="v1" resource="http://www.openlaszlo.org/images/ 
horses/horse-6-sm.jpg" />
	2. <view id="v2" resource="http://www.openlaszlo.org/images/ 
horses/animations/horse-anm-3.swf"/>
	3. <view id="v3" resource="http://www.openlaszlo.org/images/ 
animations/horse-anm-2s/"
	4. <view id="v4" resource="http://www.openlaszlo.org/images/ 
animations/horse-anm-2s"

        5. <view id="v5" resource="images/horse-3-sm.jpg"/>
        6. <view id="v6" resource="images/animations/horse-anm-1L.swf"/>
        7. <view id="v7" resource="images/animations/horse-anm-2s/"/>
        8. <view id="v8" resource="images/animations/horse-anm-2s"/>

Background: In the case of URL's (1, 2, 3, and 4) the resources  
are loaded
at runtime through HTTP. In the case of local file references  
(5, 6,
7, 8) the resources are compiled as part of the LZX application.

1 and 5 work in DHTML and Flash as expected.

In general since SWF movie resources are not directly supported in
DHTML, we have a couple of alternatives for interpreting 6 in
DHTML. First the loader will look for png files in an immediate
subdirectory of the given directory: i.e. in the case of
"images/animations/horse-anm-1L.swf" it will look for
"images/animations/horse-anm-1L/horse-anm-1L*.png". Then, if no  
png's
are found there, it would look in the autoPng directory
"images/animations/autoPng/horse-anm-1L*.png".

However, 2 will simply not work in DHTML at this point because we
don't have a way of doing a directory listing over HTTP,  
although in
an upcoming release it will behave the same as 6.

3 and 4 will also not work in either DHTML or Flash at this  
point, for
the same reason.

7 and 8, however, will work as expected in both DHTML and Flash.

Events:

The following events are intended to be defined for views in  
both DHTML and SWF:

Events generated by Views with Animated Resources (sprites):  
onframe, onimload, onlastframe, onplay, onstop,
onopacity, onaddsubresource, onerror, ontimeout

Mouse Events: onclick, ondblclick, ondrag, onmousedown,  
onmousedragin, onmousedragout,
onmouseout, onmouseover, onmouseup, onmouseupoutside

For the moment, many of the Animation Events in DHTML are  
untested.