thanks for answering,
> I think your question and your problem is specific on how the platform will
> handler user interaction, especially for entryFields.
Actually, no. It is about the event "InteractionCompleted". Who is
required to generate this event. It can not be a result of the
> >here is another technical question, this time about the Interaction
> >It is written in 41.1 2c in case of a
> I think it's rather in 41.4 2c for others.
oppps. Yes. But no problem for the experts, right? :-)
> >SetInteractionStatus(false) action:
> >"...generate the InteractionCompleted Event"
> >How about removing this sentence?
> >Reason: For example, you have an Entryfield, which is interactible. With
> >some means the user terminates this interaction, I would expect the
> >Entryfield to generate a IteractionCompleted Event on it's own.
> Here my question is : how (with which means) will the user terminates the
> interaction ? I think this is the source of your question.
No. This is another interesting question. In our implementation you have
to use a sepcific key to do that (e.g. the "ok" for a Remote Control, or
the "tab" for keyboards (just like Windows is doing)). This is
implementation depending, and might be subject for a profile.
> > This
> >event will be used by a friedly MHEG app to fire a link which sets the
> >Interaction Status to false (which is the only way to change the
> >interaction status). A second "interaction completed" it not that good.
> In my understanding, with a platform that do not handle unspecified tasks
> or events, I would expect that when the user have finished to enter chars
> in the entryField, it terminates the entry with a specific userInput event
> Then this userInput event could fire a link the set the interaction status
> to false and generates (but only once) the interactionCompleted event.
This is explicitly forbidden, since the "interacting" Entryfields
catches all the user input events. See the section 53.5.
Reason for this is, that one might wnat to use the RemoteControl keys to
enter characters, e.g. with the up/down changing the character, and the
left/right to change the position. This is an abstraction level for the
> the same, an EntryFieldFull event could fire another link that also set the
> interactionStatus to false.
This can be done, but this does not work when the entryfield is simply
> IMHO, it is rather the whole paragraph 43.3 4 which is confusing or should
> be either removed or explained. What does it mean by "because the user
> terminates the entry" ? It isn't said anything on how the user is supposed
> to terminates the entry here or I perhaps missed something.
It's up to the implementation, I think, since we can not foresee the
available keys on the remote or keyboard.
> >Main issue behind: Who is in charge to generate the InteractionCompleted
> >event? We suggest that it is comming from the EntryField object itself.
> All can be discussed. I'm usually opened to all necessary changes,
> especially when it allows to make things clearer for everybody.
At least it should be clarified.
My clarification would be to write somewhere: "It is in the
responsibility of the Interactible object to generate the Interaction
Completed Event, when the user has indicated that the interaction is
completed by an implemenation depending mechanism."
> >Additionally: In the same paragraph, it is missing that the interaction
> >status should be set to false, if a appropriate action is executed.
> I agree.
I think this is obvious.
We should make up a list of issues for the upcoming Stockholm meeting.
SC29WG12 might want to see a list of things, in order to judge about a
-- GMD FOKUS German National Research Center for Information Technology Klaus Hofrichter Hardenbergplatz 2 D-10623 Berlin Germany mailto:email@example.com http://www.fokus.gmd.de/usr/hofrichter Tel +49 30 25499-211 Fax -202 There is a reexamination, but no reparty