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