[x3d-public] [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3
GPU Group
gpugroup at gmail.com
Sat Mar 3 12:47:19 PST 2018
> Symmetry design principle >
> StringSink : X3DSink
> {
> SFString inputOnly sttring
> MFString initializeOnly sinks [] ["CONSOLE", "CLIPBOARD"]
For symmetry, assuming StringSensor input source is controlled by the
browser (keyboard, speech recognition, clipboard paste), then StrinkSink
destinations should also be controlled by the browser - not by the scene:
StringSink : X3DSink {
SFString inputOnly string
}
On Sat, Mar 3, 2018 at 7:11 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.
>
> 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/787e4e56/attachment-0001.html>
More information about the x3d-public
mailing list