R: R: R: Urgent please

Previous real network link was not correct, the correct one is
http://service.real.com/help/library/guides/realone/ProductionGuide/HTML/htm
files/timing.htm#186758 

-----Messaggio originale-----
Da: Sjoerd Mullender [mailto:sjoerd@acm.org] 
Inviato: luned́ 18 giugno 2007 8.44
A: ___
Cc: 'Jack Jansen'; 'SMIL List'
Oggetto: Re: R: R: Urgent please

___ wrote:
>> Please explain how a bug in one implementation of SMIL makes SMIL 
>> totally
> useless?
> 
> Yes sorry, that was frustration, it doesn't mean nothing.
> 
>> Have you tried other players, e.g. ambulant or GRiNS?
> 
> I tried ambulant but it has problems to show static gif or png images, 
> so even pages that works on realplayer doesn't work there :( Grins 
> player is not freeware or evaluation edition, so i couldn't had a 
> chance to try it
> 
>> The first version below is a copy of your version with all 
>> superfluous
> attributes removed. 
> 
> And it doesn't work. I arrived to this version since excl didn't work, 
> i know it's a bad way of code it...
> 
>>  The second is an equivalent version that uses excl
> 
> That's a sort of what i tried in first instance (your version is 
> clearer) but unfortunately it doesn't work.
> I uploaded the presentation on rapidshare, so if maybe you want to try 
> it, you could check if it's a realplayer bug (so i can notice them or 
> something like that) or it's me that is doing something wrong..
> http://rapidshare.com/files/37735652/bug.rar.html
> Index.smil works good since there are only some animation, while 
> storia.smil is the bugged one, clicking on second menu link and then 
> the first one, will show images of both links, instead of removing 
> them =\
> 
> Hope you have some time to test it and let me know if i should report 
> to RealPlayer (in some way) the bug.
> Thanks in advance

The attached seems to work.  What I did was simplify the code more.  I
removed all the z-index manipulation, but instead did the overlays in the
excl's.  Looks ok in the RealPlayer.


> 
> -----Messaggio originale-----
> Da: Sjoerd Mullender [mailto:sjoerd@acm.org]
> Inviato: domenica 17 giugno 2007 14.03
> A: ___
> Cc: 'Jack Jansen'; 'SMIL List'
> Oggetto: Re: R: Urgent please
> 
> On 06/17/2007 01:04 PM, ___ wrote:
>> Well, if realplayer can't handle it, then SMIL is totally useless. I 
>> mean,
> 
> Please explain how a bug in one implementation of SMIL makes SMIL 
> totally useless?
> Have you tried other players, e.g. ambulant or GRiNS?
> 
>> if it handle just the base things like transitions of slides, then i 
>> could use powerpoint for a presentation. The nice thing of SMIL 
>> should be the interactivity. After 2 weeks i couldn't handle 
>> succesfully to load on same page objects according to what is 
>> selected from menu. Use href to link to external .smil files is 
>> terrible and senseless, but seems the only thing that works.
>> I would expect to use <excl> group and fix things: no! It just 
>> doesn't work, i understood that only the begin event should be 
>> described for each excl child and excl will handle to exclusively 
>> load the child group. Obviously that doesn't work, and objects from 
>> other excl children are still visible for no reason (no, i didn't use 
>> the fill="hold"). I tried several tutorial with excl, but only those 
>> that load just an image per child works.. If i start from those and 
>> add groups as excl child, then all mess up, sooner or late.
>> Is there any template that works on realplayer or any other player 
>> where SMIL has sense and interactive presentation works?
>> Please answer, since i'm quite frustrated
> 
> I'm not really getting a warm, fuzzy feeling from trying to help you.
> 
> There are a few things you could try to get those textstreams to end 
> when you click on the button, but first I would try to *simplify* the 
> code by removing begin/end attribute values that are already implied 
> by the timing model.  The first version below is a copy of your 
> version with all superfluous attributes removed.  The second is an 
> equivalent version that uses excl.  The second version would be the 
> preferred way of doing it.  I think they should both do what you seem 
> to want, but I cannot guarantee that the RealPlayer does this 
> correctly.  If it doesn't, then it's a bug in the RealPlayer, not in SMIL.
Don't confuse the two.
> 
> <body>
>   <par dur="indefinite">
>     <par id="A_par" begin="bt_A.activateEvent" end="bt_B.activateEvent">
>       ......
>     </par>
>     <par id="B_par" begin="bt_B.activateEvent" end="bt_A.activateEvent">
>       <par id="B_par_text1" begin="0s;arrow_b.activateEvent"
> end="arrow_f.activateEvent">
> 	<textstream id="B_text1" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_a" fill="freeze"/>
> 	<textstream id="B_text2" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_b" fill="freeze"/>
>       </par>
>       <par id="B_par_text2" begin="arrow_f.activateEvent"
> end="arrow_b.activateEvent">
> 	.......
>       </par>
>     </par>
>   </par>
> </body>
> 
> <body>
>   <excl dur="indefinite">
>     <par id="A_par" begin="bt_A.activateEvent">
>       ......
>     </par>
>     <excl id="B_par" begin="bt_B.activateEvent">
>       <par id="B_par_text1" begin="0s;arrow_b.activateEvent">
> 	<textstream id="B_text1" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_a" fill="freeze"/>
> 	<textstream id="B_text2" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_b" fill="freeze"/>
>       </par>
>       <par id="B_par_text2" begin="arrow_f.activateEvent">
> 	.......
>       </par>
>     </par>
>   </par>
> </body>
> 
> 
>> -----Messaggio originale-----
>> Da: Sjoerd Mullender [mailto:sjoerd@acm.org]
>> Inviato: domenica 17 giugno 2007 12.40
>> A: Jack Jansen
>> Cc: ___; 'SMIL List'
>> Oggetto: Re: Urgent please
>>
>> On 06/17/2007 12:47 AM, Jack Jansen wrote:
>> --
>> Sjoerd Mullender
>>> It is a bit difficult to read your code, but the problem may be that 
>>> your mixing up scheduled end and event-based end.
>>>
>>> if bt_A.activateEvent is fired then two things happend immediately:
>>> 1. B_par ends
>>> 2. B_text2 ends
>>>
>>> You're expecting that the end of B_par raises B_par.end which in 
>>> turn leads to B_text2 ending. This seems like a reasonable 
>>> expectation, but I'm not 100% sure it is correct. "B_par.end" is 
>>> different from
>>> "B_par.endEvent": the first one is scheduled and the second one is 
>>> event-based.
>>>
>>> The exact distinction between those two mechanisms can be found in 
>>> the SMIL standard (in the timing section), but the hand-waving 
>>> explanation is that scheduled timing is pre-computed into the 
>>> timegraph (similar to seq children starting when their predecessor 
>>> ends, etc) whereas event-based timing happens on the fly (the 
>>> timegraph is computed as if end="indefinite", I think).
>>>
>>> I'm not sure whether the standard specifies what should happen in 
>>> this case (a scheduled timing relationship depending on an 
>>> event-based timing relationship), maybe Sjoerd or someone else who 
>>> understands this better than me can explain?
>> When an element ends because of an event, the end condition is 
>> reevaluated and repropagated.
>>
>>> But what I am sure of is that with a construct like this you're 
>>> descending into the deep damp cellars of the SMIL timing model, so 
>>> you're quite likely to stumble upon a bug. My suggestion would be to 
>>> change the "B_par.end" into "B_par.endEvent", thereby making 
>>> everything event-based, and hoping that that fixes the problem.
>>>
>>> On  16-Jun-2007, at 23:56 , ___ wrote:
>>>
>>>> This situation is extremely easy to understand, please give me a 
>>>> reply please. I'm using real player.
>>>>
>>>>   <body>
>>>>     <par dur="indefinite">
>>>> <par id="A_par" begin="bt_A.activateEvent" 
>>>> end="bt_B.activateEvent"> ......
>>>> </par>
>>>> <par id="B_par" begin="bt_B.activateEvent" 
>>>> end="bt_A.activateEvent"> <par id="B_par_text1"
begin="0s;arrow_b.activateEvent"
>>>> end="B_par.end;arrow_f.activateEvent">
>>>> <textstream id="B_text1" src="..."
>>>> rn:backgroundOpacity="0%" transIn="fade_1" region="text_B_a"
>>>> end="B_par_text1.end;bt_A.activateEvent" fill="freeze"/> 
>>>> <textstream id="B_text2" src="..."
>>>> rn:backgroundOpacity="0%" transIn="fade_1" region="text_B_b"
>>>> end="B_par_text1.end;B_par.end" fill="freeze"/> </par> <par 
>>>> id="B_par_text2" begin="arrow_f.activateEvent"
>>>> end="B_par.end;arrow_b.activateEvent">
>>>> .......
>>>> </par>
>>>> </par>
>>>>     </par>
>>>>   </body>
>>>> </smil>
>>>>
>>>> Why when B_text1 and B_text2 are visible, and i click on bt_A, only
>>>> B_text1
>>>> disappear?
>>>> The difference between B_text1 and B_text2 is that the end differ 
>>>> in this
>>>> way:
>>>>
>>>> B_text1 --> B_par_text1.end;bt_A.activateEvent
>>>> B_text2 --> B_par_text1.end;B_par.end
>>>>
>>>> BUT, since B_par group has the end attribute set to: 
>>>> bt_A.activateEvent, shouldn't B_par.end and bt_A.activateEvent act 
>>>> the
>> SAME way?
>>
>> It seems to me you've uncovered a bug in the RealPlayer.  When you 
>> click on bt_A, since B_par has an end="bt_A.activateEvent", it ends.
>> It doesn't matter what's inside, but all that is inside should end 
>> then as well, so this definitely includes B_text1 and B_text2.  There 
>> is no two ways about it, and it doesn't matter what their end 
>> attributes
> say, they should end.
>> --
>> Sjoerd Mullender
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
>> 16/06/2007 12.50
>>  
>>
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
>> 16/06/2007 12.50
>>  
>>
>>
> 
> 
> --
> Sjoerd Mullender
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
> 16/06/2007 12.50
>  
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
> 16/06/2007 12.50
>  
> 


--
Sjoerd Mullender

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 16/06/2007
12.50
 
  

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007
8.23

Received on Monday, 18 June 2007 11:54:32 UTC