|
This page wants to give X3D the capability to input text in an as versatile form as it is possible with forms in HTML.
X3D, maintained by the Web3D Consortium, is a language that allows for interactive 3D on the web.
This is similar to what HTML, Flash and SVG is for 2D.
However, X3D lacks a feature-complete means for text input. Currently there is the KeySensor node, which allows for
reading individual key strokes and there is the StringSensor, which allows to enter complete strings. Though the
features of the StringSensor node are very limitted. The only possible key for editing is the backspace key. There
is no maintenance of a cursor position, multi line input, text selectoin, etc.
See
Key device sensor component in the X3D specification for details.
To have the same features available in X3D that is state of the art in other technologies like web forms in HTML, or GUIs for native applications,
a TextSensor node should be developed. This page will show progress on this.
Features of the TextSensor node
Before listing the desidred features we should explain what we mean with 'the containing GUI system':
An X3D scene needs a piece of software that runs it. This software is called X3D player. It takes the role
for X3D that a web browser takes for HTML. The X3D player is usually one application that runs among many inside
the GUI (graphical user interface) of an operating system. This GUI may be the windowing system of Microsoft Windows,
or X11 in the case of Linux or Unix. We call this GUI the 'containing GUI system' because it is somehow the container
of the X3D player with the X3D scene.
Editing features like in normal GUIs:
The position of an input cursor should be maintained. It can be controlled by cursor keys and should follow the conventions
used by the containing GUI system.
Full integration into the containing GUI system:
This means things like the blinking frequency of the cursor should follow the guide lines from the containing GUI system used,
or that the cursor becomes invisible when the window containing the X3D scene - the X3D player - looses keyboard focus.
Multi Line input:
The input field should be capable of maintaining multiple lines of text.
Text selection and clip board access:
The user should be able to select a portion of the text with the mouse (if thats the convention of the containing GUI system) and
should be able to copy this text to the clip board of the containing GUI sytstem and insert text from the clip board into the input field.
Especially the paste feature requires security considerations because it means copying content from the clip board into an application that
was possibly downloaded from an untrusted location (web server).
Like with all features, the conventions used by the containing GUI system should be used.
- Visual appearance should be freely designable by the X3D author:
The TextSensor node should not have any visual appearance. It should only send out events through the
routing system of an X3D scene and it should be up to the X3D scene author to shape the appearance of the text input field.
Creating a text input field should be as easy as to connect the TextSensor node with
a Text node for the letters and with a Transform node that moves a cursor object.
On the other hand there should be no limitation as to how fancy this text input field can become and how much visual feed back the
user gets about the actions performed in the text input field.
- Accessibility:
The writer of the X3D player should be able to make its implementation of the TextSensor node communicate
with accessibility software so that poeple with disabilities have no disadvances using X3D.
The requirement that the conventions in the containing GUI system should be used means that these features should be part of the
TextSensor implementation, rather than being X3D code. This means that the TextSensor
node should be the part that performs things like copying to/from the clipboard and it should send to the X3D scene only updates to the
internal state. The internal state compromises of things like buffer content, cursor position, text portion selected. The TextSensr
node should also send to the X3D scene which action has been performed for an update, so that an elaborate input field can visualize
these actions.
Interface description
EXTERNPROTO TextSensor
[
eventIn SFBool enabled # request to set the focus.
eventOut SFBool isActive # TRUE if it has the focus (among other KeySensor,
# TextSensor, etc nodes)
exposedField SFInt32 maxChars # Number of characters per line. -1 = unlimitted. (default -1)
exposedField SFInt32 maxLines # Number of lines allowed. -1 = unlimitted. (default 1)
eventOut MFString buffer # contains all the entered text. May be multi-line
eventOut SFBool showCursor # TRUE if isActive is TRUE and if the browser has keyboard focus ...
eventOut SFInt32 cursorIdxX # number of character after which the cursor is located. If it is ...
eventOut SFInt32 cursorIdxY # the line number in which the cursor is located, top line is 0, ...
# doing this for proportional fonts is a bit tricky because we need knowledge about the visual representation,
# i.e. about the font used.
# Maybe we require an SFNode field that has a USE to the corresponding FontStyle node used in the visual
# representation of the field.
eventOut MFString selection # if there is selected text, this contains it, otherwise "".
eventOut MFInt32 selectionIdx # X and Y for the beginning and end of the selection in the order ...
# cursorIdxX_end, cursorIdxY_end. If there is no selection, this ...
eventOut MFString command # before a change is done, this outputs what will be done and its ...
eventOut SFTime done # after an update (various eventOuts are changed) this outputs a ...
eventOut MFString cantDo # if a command cannot be executed (e.g. going to the left if you ...
eventIn MFString set_buffer # sets the buffer to a new content.
eventIn SFInt32 set_cursorX #
eventIn SFInt32 set_cursorY #
eventIn MFInt32 set_selectionIdx #
eventOut MFString externalKey # When a key is pressed that needs external processing, etc. Tab, ...
# The first element is the name of the key, e.g. 'tab', 'esc', ...
# which modifier keys are pressed. It's in the form that the Unix ...
# pressed, and a respective letter if it is pressed. The order is ...
# independend set of keys). E.g. '---' means no modifier key is ...
# is pressed, '-c-' stands for the Ctrl key, and '--a' for the ...
# and so on.
]
|
| |
The comments have been shortened because otherwise they would destroy the layout.
They will be provided later.
__.-.__
end of document
|
