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

Thu Mar 1 06:45:46 PST 2018

 > Design Principle names
> 2. node field compatibillity
maybe could be called Profile NodeType Valance, or Profile Nodetype
Granularity ?:meaning a profile either has the whole nodetype, or drops the
whole nodetype
-  something in-appropriate for some major profiles (ie desktop vs HTML) is
consolidated into a separate node type, so a profile can drop a whole node
type rather than a field here or there.

>  Yes. And perhaps there could be a separate inputOutput field somewhere
that can be routed to,
For example one way to solve the design issue -so there's
Profile-Nodetype-Granularity- might be to look at how the HTML profile
handles textbox input/output.
Then design a new nodeType for non-html/desktop profile, that just fills in
for what desktop is missing.
That way HTML profile can skip one nodetype.

On Thu, Mar 1, 2018 at 7:13 AM, GPU Group <gpugroup at gmail.com> wrote:

>  > 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/P
>>> art01/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/brutzman
>>
>>
>> _______________________________________________
>> 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/3cd334d3/attachment.html>