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

GPU Group gpugroup at gmail.com
Sat Mar 3 06:11:53 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.

Symmetry design principle > StringSink : X3DSink
{
SFString inputOnly sttring
MFString initializeOnly sinks [] ["CONSOLE", "CLIPBOARD"]
}
-Doug

On Fri, Mar 2, 2018 at 7:32 AM, GPU Group <gpugroup at gmail.com> wrote:

> Some types of pointing devices are also singleton and 'parkable', and the
> TouchSensor isOver could be used for those to activate a StringReceiver
> node.
> 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.
>
>
>
> On Fri, Mar 2, 2018 at 7:07 AM, GPU Group <gpugroup at gmail.com> wrote:
>
>> 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.
>> Similarly for OS Copy&Paste, incoming Vox etc - to a graphics window they
>> appear as global single sources and sinks.
>> 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.
>> 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.
>> 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.
>> Some kind of encapsulatable focus method would help.
>> 0. utility nodes and global routing through protobody and inline walls
>> 1. Browser['name'] = value - the Browser object is also a global
>> singleton (but accessible only through SAI)
>> 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
>> 3. X3DFocus abstract type, and some way to use it
>> a)  derive a node
>>  StringFocus :X3DFocus {
>> SFString inputOutput string [NULL]
>> SFBool inputOutput focus [TRUE]
>> }
>>
>> b) nodetype Focus : X3DFocus
>> {
>> SFBool inputOutput focus [TRUE]
>> }
>>
>> c) like StringFocus, except with the copy&paste target
>> nodetype StringBoard : X3DFocus, X3DClipboard {
>> (same as StringFocus)
>> }
>> - 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
>>
>> d) like some of the above, except 'owning' some of the nodes its
>> controlling
>> X3DFocus {
>> SFBool inputOutput focus [TRUE]
>> SFNode initializeOnly StringSensor NULL
>> SFNode initializeOnly Clipboard NULL
>> }
>>
>> -Doug
>>
>> On Thu, Mar 1, 2018 at 7:45 AM, GPU Group <gpugroup at gmail.com> wrote:
>>
>>> > 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/Textbox
>>>>>> Widget.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/20180303/8f7bf786/attachment-0001.html>


More information about the x3d-public mailing list