<div dir="ltr">
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> 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.</span>
<br><div><br></div><div>Symmetry design principle > StringSink : X3DSink</div><div>{</div><div>SFString inputOnly sttring</div><div>MFString initializeOnly sinks [] ["CONSOLE", "CLIPBOARD"]</div><div>}</div><div>-Doug</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 2, 2018 at 7:32 AM, GPU Group <span dir="ltr"><<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Some types of pointing devices are also singleton and 'parkable', and the TouchSensor isOver could be used for those to activate a StringReceiver node.<div>In the case of touch screens including mutlitouch capabile, a browser can provide' a draggable, parkable singleton pointer to act like a singleton mouse and support the TouchSensor isOver.</div><div><br><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 2, 2018 at 7:07 AM, GPU Group <span dir="ltr"><<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">StringSensor is already a 'global' singleton and if you put 3 DEF StringSensor routed to 3 Text in a scene and start typing, you'll get the same thing coming out in all 3 Text.<div>Similarly for OS Copy&Paste, incoming Vox etc - to a graphics window they appear as global single sources and sinks.<br><div>What's missing is 'Focus' - a design pattern used in windowing and widget UI elements, whereby only one of a type is enabled at a time.</div><div>For web3d an equivalent can be prototyped as Don mentioned with utility nodes and routing to turn off any you don't want receiving at any one time.</div><div>The problem is object-oriented > encapsulation - you might have StringSensors in proto bodies, inlines and hard to track places, and routing from a central location can be awkward, with spaghetti routes through proto and inline walls.</div><div>Some kind of encapsulatable focus method would help.</div><div>0. utility nodes and global routing through protobody and inline walls</div><div>1. Browser['name'] = value - the Browser object is also a global singleton (but accessible only through SAI)</div><div>2. StringSensor.field- since the internal part of StringSensor is already a global singleton, putting a field on each instance and doing some internal code to a shared global singleton </div><div>3. X3DFocus abstract type, and some way to use it</div><div>a) derive a node</div><div> StringFocus :X3DFocus {</div><div>SFString inputOutput string [NULL]</div><div>SFBool inputOutput focus [TRUE]</div><div>}</div></div><div><br></div><div>b) nodetype Focus : X3DFocus</div><div>{</div><div>SFBool inputOutput focus [TRUE]</div><div>}</div><div><br></div><div>c) like StringFocus, except with the copy&paste target</div><div>nodetype StringBoard : X3DFocus, X3DClipboard {</div><div>(same as StringFocus)</div><div>}</div><div>- by putting copy&paste in here instead of StringSensor, it provides a inout field so you can route from normal scenery here, set the focus, and then copy out to the OS clipboard</div><div><br></div><div>d) like some of the above, except 'owning' some of the nodes its controlling</div><div>X3DFocus {</div><div>SFBool inputOutput focus [TRUE]</div><div>SFNode initializeOnly StringSensor NULL</div><div>SFNode initializeOnly Clipboard NULL</div><div>}</div><div><br></div><div>-Doug</div></div><div class="m_247288636562676444HOEnZb"><div class="m_247288636562676444h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 1, 2018 at 7:45 AM, GPU Group <span dir="ltr"><<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px">> Design Principle names</span></div>> 2. node field compatibillity<div>maybe could be called Profile NodeType Valance, or Profile Nodetype Granularity ?:meaning a profile either has the whole nodetype, or drops the whole nodetype</div><div>- 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.<br class="m_247288636562676444m_-8739021244371672728m_8042282469579275676gmail-Apple-interchange-newline">
<br></div><span><div>>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Yes. And perhaps there could be a separate inputOutput field somewhere that can be routed to,<span> </span></span></div></span><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">Then design a new nodeType for non-html/desktop profile, that just fills in for what desktop is missing.</span></div><div><span style="font-size:12.8px">That way HTML profile can skip one nodetype.<br></span><div><br></div><div>
<div><br></div></div></div></div><div class="m_247288636562676444m_-8739021244371672728HOEnZb"><div class="m_247288636562676444m_-8739021244371672728h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 1, 2018 at 7:13 AM, GPU Group <span dir="ltr"><<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> > 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.</span>
<br><div><br></div></span><div>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.</div><div>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</div><span><div><br></div><div>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> 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.</span>
</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div></span><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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.</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Browser["stringsensor_singeton<wbr>"] = this;</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Then within the TextBox protobody, can test if another node has ownership before routing output to textbox.</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">if( Browser]"stringsensor_singleto<wbr>n"] != this ) skip = true;</span></div><div>.</div><div>And maybe some Design Principle names::</div><div>1. node conservation - limit number of convenience nodes - cost of web3d and browser maintenance = f(# of node types)</div><div>2. node field compatibility - if adding a field to a node, it should apply to all profiles, otherwise make a new nodetype</div><div>3. object orientation - help protos encapsulate and avoid a mess of routes </div><div>4. symmetry - if there's something going one way, scene designers will expect its complement and be puzzled if not there</div><div><br></div><div>-Doug</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_247288636562676444m_-8739021244371672728m_8042282469579275676h5">On Wed, Feb 28, 2018 at 10:53 AM, Don Brutzman <span dir="ltr"><<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_247288636562676444m_-8739021244371672728m_8042282469579275676h5">[shifted issue discussion to x3d-public, seeking broad feedback]<br>
<br>
Again thanks for your thoughtful submission Doug.<br>
<br>
Mantis 1214 includes multiple StringSensor issues. Detailed notes have been added to the issue, all feedback welcome.<br>
<br>
This issue contains multiple suggestions. Today's initial review by specification editors follows:<br>
<br>
<a href="http://www.web3d.org/member-only/mantis/view.php?id=1214" rel="noreferrer" target="_blank">http://www.web3d.org/member-on<wbr>ly/mantis/view.php?id=1214</a><br>
==============================<wbr>==============================<wbr>=====<br>
brutzman (developer)<br>
<br>
a. OS drag+drop for copy/paste is desirable. Speech-to-text might also aid in accessibility. Specification says:<br>
<br>
"A StringSensor node generates events as the user presses keys on the keyboard."<br>
<br>
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."<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Improved design also needs to consider W3C accessibility guidelines, both for thoroughness and HTML compatibility.<br>
* WAI-ARIA Overview Web Accessibility Initiative W3C<br>
* <a href="https://www.w3.org/WAI/intro/aria" rel="noreferrer" target="_blank">https://www.w3.org/WAI/intro/a<wbr>ria</a><br>
<br>
==============================<wbr>==============================<wbr>=====<br>
RFPuk (developer)<br>
<br>
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.<br>
<br>
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".<br>
==============================<wbr>==============================<wbr>=====<br>
<br>
<br>
On 2/14/2018 6:03 AM, Roy Walmsley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi again Doug,<br>
<br>
Thanks for this addendum to your previous comment. I have added it as a note<br>
to issue 1214, available to Web3D members at<br>
<a href="http://www.web3d.org/member-only/mantis/view.php?id=1214" rel="noreferrer" target="_blank">http://www.web3d.org/member-on<wbr>ly/mantis/view.php?id=1214</a>.<br>
<br>
All the best,<br>
<br>
Roy<br>
<br>
-----Original Message-----<br>
From: x3d [mailto:<a href="mailto:x3d-bounces@web3d.org" target="_blank">x3d-bounces@web3d.org</a>] On Behalf Of Spec Feedback<br>
Sent: 02 January 2018 13:48<br>
To: <a href="mailto:x3d@web3d.org" target="_blank">x3d@web3d.org</a><br>
Subject: [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3<br>
<br>
-- Submitter indicates that this comment may be public: *Yes* --<br>
<br>
Comment on 19775-1: Abstract X3D Definitions - V3.3<br>
21.4.2 StringSensor<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/P<wbr>art01/components</a><br>
/keyboard.html#StringSensor<br>
<br>
-----------------<br>
addendum to previous comment > StringSensor in TextBox usage scenario:<br>
<a href="http://dug9.users.sourceforge.net/web3d/tests/DIS/UI/TextboxWidget.x3d" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/tests/DIS/UI/Textbox<wbr>Widget.x3d</a><br>
<br>
-----------------<br>
<br>
Submitted on Tuesday, 2018, January 2 - 5:47am by (Doug Sanden )<br>
IP: 104.205.111.195<br>
<br>
See: <a href="http://www.web3d.org/node/1694/submission/1655" rel="noreferrer" target="_blank">http://www.web3d.org/node/1694<wbr>/submission/1655</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
x3d mailing list<br>
<a href="mailto:x3d@web3d.org" target="_blank">x3d@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d_web3d.org</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
x3d mailing list<br>
<a href="mailto:x3d@web3d.org" target="_blank">x3d@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d_web3d.org</a><br>
<br>
</blockquote>
<br>
<br>
all the best, Don<span class="m_247288636562676444m_-8739021244371672728m_8042282469579275676m_7771862219241513277HOEnZb"><font color="#888888"><br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma<wbr>n</a><br>
<br>
</font></span><br></div></div>______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>