R: R: Urgent please

> 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


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

Received on Sunday, 17 June 2007 13:03:24 UTC