[x3d-public] [x3d] Spec Comment by on 19775-1: Abstract X3D Definitions - V3.3
GPU Group
gpugroup at gmail.com
Fri Mar 2 06:32:16 PST 2018
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/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/20180302/c535030c/attachment-0001.html>
More information about the x3d-public
mailing list