<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>
<p style="margin-bottom: 0cm;">Hi all</p>

<p style="margin-bottom: 0cm;">Sorry for writing so many e-mails for just one idea. Now I have seized the lunch break to summarize the suggestion, maybe it can explain the idea better:</p>

<ol>
        <li>
        <p style="margin-bottom: 0cm;">Is there anything in X3D that makes the following DRAFT proposal obsolete?</p>
        </li>
        <li>
        <p style="margin-bottom: 0cm;">DRAFT Proposal for simplified handling of keystrokes or other input of character streams via KeySensor and StringSensor.<br/>
        a) Each <strong>X3D grouping node</strong> defines two additional fields<br/>
        <field accessType='inputOutput' name=<strong>'canHaveFocus' </strong>type='SFBool' value='false'/><br/>
        <field accessType='inputOutput' name=<strong>'isAvatar' </strong>type='SFBool' value='false'/><br/>
        b) the behaviour is as follows:<br/>
        b.1) <strong>canHaveFocus == false</strong>: well-known "old" behaviour, no change<br/>
        b.2) <strong>canHaveFocus == true && isAvatar == false</strong>: the browser may select this group together with all static and dynamic children to get the "focus" by some means. Only one group and its children can have the focus at any time. Having the focus means all StringSensor nodes and KeySensor nodes contained in the group are enabled regardless of the value of their "enabled" field. The browser SHOULD graphically indicate, which geometry has got the focus, e.g. by highlighting or by drawing a 2-dimensional "frame" around the geometry.<br/>
        b.3) <strong>canHaveFocus == true && isAvatar == true</strong>: same behaviour as with b.2), but the avatar gets the focus any time, when no other geometry has the focus, even, if the avatar is invisible currently.</p>
        </li>
</ol>

<div>Have a nice day</div>

<div>Christoph</div>
</div>

<div>
<div name="quote" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left-color: rgb(195, 217, 229); border-left-width: 2px; border-left-style: solid; -ms-word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin: 0px 0px 10px;"><b>Gesendet:</b> Donnerstag, 17. Januar 2019 um 09:44 Uhr<br/>
<b>Von:</b> "Christoph Valentin" <christoph.valentin@gmx.at><br/>
<b>An:</b> "Christoph Valentin" <christoph.valentin@gmx.at>, "Leonard Daly" <Leonard.Daly@realism.com>, x3d-public@web3d.org<br/>
<b>Betreff:</b> Re: [x3d-public] Mac-unaware PageUp/PageDown, Viewpoint list, navigation keys?</div>

<div name="quoted-content">
<div class="mail_android_message" style="padding: 0.5em; line-height: 1;">Maybe its silly, but I thought: 1) I can *ride* a locomotive and * use* its controls or 2) I can *be* a locomotive<br/>
<br/>
Like a Horse + Rider = a single entity<br/>
--<br/>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</div>

<div class="mail_android_quote" style="padding: 0.3em; line-height: 1;">Am 17.01.19, 09:28, Christoph Valentin <christoph.valentin@gmx.at> schrieb:
<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div class="mail_android_message" style="padding: 0.5em; line-height: 1;">Plus a "special handling" for avatars, where the pilot avatar can have an "always on" focus to supersede Standard navigation by avatar specific movement Strategy..........<br/>
--<br/>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</div>

<div class="mail_android_quote" style="padding: 0.3em; line-height: 1;">Am 17.01.19, 07:45, Christoph Valentin <christoph.valentin@gmx.at> schrieb:
<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div class="mail_android_message" style="padding: 0.5em; line-height: 1;">Each grouping node would need a new field:<br/>
<br/>
<field accessType='inputOutput' type='SFBool' name='canHaveFocus' value='false'/><br/>
<br/>
and the rest was up to the browser.<br/>
--<br/>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</div>

<div class="mail_android_quote" style="padding: 0.3em; line-height: 1;">Am 17.01.19, 07:25, Christoph Valentin <christoph.valentin@gmx.at> schrieb:
<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div class="mail_android_message" style="padding: 0.5em; line-height: 1;">And what about a concept of "having the focus":<br/>
<br/>
If a grouping node "had the focus", then all KeySensor and StringSensor nodes within this group would become "enabled".<br/>
<br/>
KR<br/>
Christoph<br/>
--<br/>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</div>

<div class="mail_android_quote" style="padding: 0.3em; line-height: 1;">Am 16.01.19, 23:22, Christoph Valentin <christoph.valentin@gmx.at> schrieb:
<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div class="mail_android_message" style="padding: 0.5em; line-height: 1;">Maybe my opinion is not important, but I think these concrete hints which key to use for which navigation function should be completely avoided in X3D Spec.<br/>
<br/>
Isn't it enough to have the abstract/virtual concepts of "indicating forward/backward/left/right/up/down", "fast/slow", "touch", "drag" by "some means that are up to the Browser"?<br/>
<br/>
The Events that are created by the sensor nodes have to be specified well, on the other hand. <br/>
<br/>
A different story is the Network Sensor, where the protocol should be specified to the bits. <br/>
<br/>
Just my opinion and just Two Cent:-)<br/>
--<br/>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</div>

<div class="mail_android_quote" style="padding: 0.3em; line-height: 1;">Am 16.01.19, 21:37, Leonard Daly <Leonard.Daly@realism.com> schrieb:
<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div class="moz-cite-prefix">Don,</div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix">It could be the answer is Mac's are broken and so is the spec, but for different reasons. I don't consider this Mac enlightenment, but Apple darkening (as in the dark side).</div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix">While most people have multiple-button mouse (I have 4 buttons and a track wheel), Mac uses have had to suffer with simplicity of a single button. I think the "apple" key along with a button press is the (poor) equivalent of a right click.</div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix">The way the spec is broken is for phones  and other touch sensitive devices. These devices do not have any concept of mouse-over or (any) button press. The situation is worse if you are in a headset without buttons (e.g., cardboard) and cannot reach the screen.</div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix">It may be necessary to highly recommend to developers to provide a user-interface means of accessing the navigation list and other such items rather than relying on device features which may or may not be present.</div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix">Leonard Daly</div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix"> </div>

<div class="moz-cite-prefix"> </div>

<blockquote>
<pre class="moz-quote-pre">First a personal confession: Mac enlightenment has never quite befallen upon me... please be forgiving!  8)

Second: twice this week, when doing a demo and naively saying "oh just select PageDown or PageUp to navigate through the viewpoints," Mac users responded "oh now we don't have those keys on a Mac" and also "No I'd have to go find a mouse before being able to right-click for a viewpoint list."

Question:  Really??!

Next: does this mean our X3D Specification recommendations are flawed or insufficient for common practice?

==============================================
X3D Architecture and base components
Annex G Recommended navigation behaviours
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/behaviours.html" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/behaviours.html</a>

==============================================
G.2 Select from multiple viewpoints

cube G.2 Select from multiple viewpoints

User navigation in X3D environments includes definition of multiple viewpoints. Where the user is allowed to freely select between viewpoints, typical controls allow simple selection of:

     Home (Initial) ViewPoint,
     Last (Final) Viewpoint,
     Next Viewpoint in Sequence, and
     Previous Viewpoint in Sequence.

This annex recommends using the following keys:

HOME    Initial Viewpoint
PGDN    Next Viewpoint
PGUP    Previous Viewpoint
END     Final Viewpoint

==============================================
G.3 Emulate pointing device

The pointing device is used to control navigation through the scene. Where the user is allowed to interact using the pointing device, typical controls allow up/down/right/left pointing device movement to control movement of the viewpoint.
The objective is not to actually move the screen tracking cursor, but to allow navigation control as if the tracking cursor or pointer is moved under control of the pointing device.

This annex recommends using the following (arrow) keys to emulate relative tracking pointer movement as follows:

UP        Up
DOWN      Down
LEFT      Left
RIGHT     Right

Movement left/right/up/down refers to motion of the user's view while navigating.

Activation of these keys causes movement of the viewpoint according to currently selected navigation type:

WALK:      forward/backward/left/right
FLY:       forward/backward/left/right
EXAMINE:   orbit up/down/left/right around center of rotation
            with camera pointed at center of rotation

==============================================
G.4 Select or activate pointing device

The pointing device is used to provide a means of selecting of a scene element. Where the user is allowed to use this, the following action is recommended: activate pointing device (left mouse click).

This annex recommends using the following key:

ENTER  Left Mouse Click

==============================================
G.5 Disable/enable keyboard

It is recommended that the browser provide a means for the author to enable and disable the keyboard.

==============================================

all the best, Don
</pre>
</blockquote>

<p> </p>

<div class="moz-signature">--<br/>
<font class="tahoma,arial,helvetica san serif" color="#333366"><font size="+1"><b>Leonard Daly</b></font><br/>
3D Systems & Cloud Consultant<br/>
LA ACM SIGGRAPH Past Chair<br/>
President, Daly Realism - <i>Creating the Future</i> </font></div>
_______________________________________________ x3d-public mailing list x3d-public@web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org</blockquote>
</div>
_______________________________________________ x3d-public mailing list x3d-public@web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div></div></body></html>