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

Received on Sunday, 17 June 2007 12:02:59 UTC