R: Urgent please

Well, if realplayer can't handle it, then SMIL is totally useless. I mean,
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 

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

Received on Sunday, 17 June 2007 11:04:29 UTC