[x3d-public] IntegerTrigger [was: BooleanToggle output]

[Don Brutzman]

[levels of indentation in reply not being honored by mailer, hopefully transcribed here OK.  focused on your recent reply prose.]

On 9/24/2017 8:14 AM, Andreas Plesch wrote:
> 
> http://x3dom-integertrigger.glitch.me/IntegerTrigger_test.x3d has now a way to test set_boolean false:
> Clicking on the left cone starts a timer which switches left text off right away and after 2 seconds. So one can click on the right cone to switch left text back on and see if it is switched off after 2 seconds. It is, for all browsers I tested.
> 
> Octaga, view3dscene and x_ite all trigger on set_boolean false.

it looks like it did the same in InstantReality, though timing seemed immediate.

these are helpful tests but it is certainly a challenge to sleuth how well different players conform.

> Apart from avoiding backwards incompatible changes, there are other arguments but overall I agree restricting triggering to 'True' input adds simplicity and clarity. I do think such would need to be considered as a backwards incompatible change.
> 
> I would probably prefer to avoid confusion between spec. language and tool tip language, meaning marking the set_boolean true explanations in the tool tips somehow.

Very good.  Have amended hint in tooltips.

"Hint: input event set_boolean false has no effect."

to

"Hint: for logical consistency, input event set_boolean false has no effect (under review as part of Mantis issue 519)."

> In terms of an IntegerTrigger node for x3dom, there just needs to be a decision. I lean towards being compatible with other browsers and a straight interpretation of the current spec. language. There also could be a IntegerTrueTrigger to enable use of the new behaviour.

Throughout this effort let's decide on simplest and most consistent approach with honoring 'true' events only.  Specification process can review and confirm.

[now manually reconstructing email-thread levels, hopefully OK]

>>>         Looking into TimeTrigger next.
>> 
>>     same as point (2), only honoring true events for simplicity and logical clarity.
> 
> Agreed in general. Likely browsers currently also honor false events but will test.

OK, great let's keep converging on best answer.  As before, reacting to false events is logically confusing and makes design/debugging quite convoluted.

>>     Feels like we got another step closer, thanks...
>> 
>>     Once we have all this distilled in Mantis issue capturing best-effort prose, it will hopefully be straightforward to confirm resolution.
> 
> I do not have a sense of how widely the event utilities are used, eg. what the impact of such a resolution would be. I think it would be a positive change but a change nonetheless recognizing that this is the behaviour as it was originally intended.

Well, "originally intended" is a bit strong!  Correctness and usefulness was always intended, functional design of these nodes has just turned out to be more subtle than expected.  I think the original ambiguities in spec prose reflect a lack of clarity that continued practice has helped us to understand.

Getting the event utility functional descriptions distilled to the most concise, coherent and consistent approach will help animation correctness and meet the original intent of this component.  Ignoring set_boolean false events definitely helps.

Again thanks for your efforts together on this design Andreas.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman