[x3d-public] [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3

Thu Mar 1 06:13:40 PST 2018

  > b. Regarding "no in-scene initialization text could be copied out." Any
default string value might instead be placed in the target of the
StringSensor output. Thus no initial value needed for enteredText/finalText.

Yes. And perhaps there could be a separate inputOutput field somewhere that
can be routed to, and that can copy out.with Drag&Drop, that would be
converted to Vox, or copied and pasted out of the scene, so there's some
copy paste symmetry.
A reason for making it separate from the outputOnly field on StringSensor:
so you can route to it without causing a chain reaction output event that
goes back into your scene nodes that are listening for StringSensor input

> c. An author might want multiple StringSensor nodes, choosing when to
enable/disable each. Simultaneous operation might be desirable. Further an
author can achieve "singleton" status among multiple StringSensor nodes by
ROUTEing each enable field to other StringSensor nodes via a BooleanToggle
node. Thus no new field such as "singleton" needs to be added.

Yes and maybe another way to achieve object-oriented TextBox protos
-without needing to route between them through proto and inline barriers -
is via SAI Browser object: I haven't tried it but can you just add a
"name"= "value" to Browser? its a global object and reachable from within
all protos via SAI.
Browser["stringsensor_singeton"] = this;
Then within the TextBox protobody, can test if another node has ownership
before routing output to textbox.
if( Browser]"stringsensor_singleton"] != this ) skip = true;
.
And maybe some Design Principle names::
1. node conservation - limit number of convenience nodes - cost of web3d
and browser maintenance = f(# of node types)
2. node field compatibility - if adding a field to a node, it should apply
to all profiles, otherwise make a new nodetype
3. object orientation - help protos encapsulate and avoid a mess of routes
4. symmetry - if there's something going one way, scene designers will
expect its complement and be puzzled if not there

-Doug

On Wed, Feb 28, 2018 at 10:53 AM, Don Brutzman <brutzman at nps.edu> wrote:

> [shifted issue discussion to x3d-public, seeking broad feedback]
>
> Again thanks for your thoughtful submission Doug.
>
> Mantis 1214 includes multiple StringSensor issues.  Detailed notes have
> been added to the issue, all feedback welcome.
>
> This issue contains multiple suggestions. Today's initial review by
> specification editors follows:
>
> http://www.web3d.org/member-only/mantis/view.php?id=1214
> =================================================================
> brutzman        (developer)
>
>  a. OS drag+drop for copy/paste is desirable. Speech-to-text might also
> aid in accessibility. Specification says:
>
> "A StringSensor node generates events as the user presses keys on the
> keyboard."
>
>  Consider adding "A browser implementation may optionally support
> copy/paste from the system clipboard, or speech-to-text input, as
> enteredText and finalText values in lieu of keyboard input."
>
>  b. Regarding "no in-scene initialization text could be copied out." Any
> default string value might instead be placed in the target of the
> StringSensor output. Thus no initial value needed for enteredText/finalText.
>
>  c. An author might want multiple StringSensor nodes, choosing when to
> enable/disable each. Simultaneous operation might be desirable. Further an
> author can achieve "singleton" status among multiple StringSensor nodes by
> ROUTEing each enable field to other StringSensor nodes via a BooleanToggle
> node. Thus no new field such as "singleton" needs to be added.
>
>  d. StringSensor needs to have a "description" field similar to other
> sensor nodes. We might further require browsers to indicate when KeySensor
> and StringSensor are active, further displaying the description to express
> author's intent. Hopefully this approach can be comparable to best
> practices for HTML forms.
>
>  Improved design also needs to consider W3C accessibility guidelines, both
> for thoroughness and HTML compatibility.
>  * WAI-ARIA Overview Web Accessibility Initiative W3C
>  * https://www.w3.org/WAI/intro/aria
>
> =================================================================
> RFPuk   (developer)
>
>  I suggest adding a "prompt" field which displays prompt text in an
> implementation-dependent manner. The prompt would appear when the node is
> enabled and disappear by the time the entry is completed.
>
>  I also support a "description" field but think it can be confusing to add
> additional semantics to an existing (in other nodes) field that is not
> universally applied. In addition, the content of a description field might
> not be the same as the content of a "prompt".
> =================================================================
>
>
> On 2/14/2018 6:03 AM, Roy Walmsley wrote:
>
>> Hi again Doug,
>>
>> Thanks for this addendum to your previous comment. I have added it as a
>> note
>> to issue 1214, available to Web3D members at
>> http://www.web3d.org/member-only/mantis/view.php?id=1214.
>>
>> All the best,
>>
>> Roy
>>
>> -----Original Message-----
>> From: x3d [mailto:x3d-bounces at web3d.org] On Behalf Of Spec Feedback
>> Sent: 02 January 2018 13:48
>> To: x3d at web3d.org
>> Subject: [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3
>>
>> -- Submitter indicates that this comment may be public: *Yes* --
>>
>> Comment on 19775-1: Abstract X3D Definitions - V3.3
>> 21.4.2 StringSensor
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components
>> /keyboard.html#StringSensor
>>
>> -----------------
>> addendum to previous comment > StringSensor in TextBox usage scenario:
>> http://dug9.users.sourceforge.net/web3d/tests/DIS/UI/TextboxWidget.x3d
>>
>> -----------------
>>
>> Submitted on Tuesday, 2018,  January 2 - 5:47am by  (Doug Sanden )
>> IP: 104.205.111.195
>>
>> See: http://www.web3d.org/node/1694/submission/1655
>>
>>
>> _______________________________________________
>> x3d mailing list
>> x3d at web3d.org
>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>
>>
>> _______________________________________________
>> x3d mailing list
>> x3d at web3d.org
>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>
>>
>
> 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/brutzma
> n
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180301/b0c46b7b/attachment-0001.html>