<node name="/node" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-
<tp:struct name="EventListenerMode">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A structure that encapsulates the characteristics of the event notifications
that should be sent to an EventListener in response to a call to
- DeviceEventController::registerKeystrokeListener or
- DeviceEventController::registerDeviceEventListener. </p>
+ DeviceEventController.registerKeystrokeListener or
+ DeviceEventController.registerDeviceEventListener. </p>
</tp:docstring>
<tp:member type="b" tp:name="synchronous">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< If \c True, specifies that
+ <p>If \c <code>True</code>, specifies that
DeviceEventController should block while waiting
for client to process the requested event notifications;
ordinarily should be used only when client needs to perform
</tp:member>
<tp:member type="b" tp:name="preemptive">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< If \c True, specifies that
+ <p>If <code>True</code>, specifies that
Listener is allowed to pre-empt the delivery of the event,
- effectively "consuming" it such that it is not delivered
+ effectively 'consuming' it such that it is not delivered
to the currently focussed desktop application.
Key events consumed via this API will not be
available for use by other applications or services, so this
</tp:member>
<tp:member type="b" tp:name="global">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< If \c True, specifies that
+ <p>If <code>True</code>, specifies that
Event notifications should be sent regardless of whether the
currently focussed application participates in the AT-SPI
infrastructure. On systems with the XEvIE X extension, this flag
also allows access to events which are already subject to
- interception via a "system keygrab" (as described in the X Window System
+ interception via a 'system keygrab' (as described in the X Window System
documentation for XGrabKey). The 'global' and 'preemptive' flags
should only be used together for the purposes of registering
- "system global key shortcuts" i.e. command keys for use by the
+ 'system global key shortcuts' i.e. command keys for use by the
assistive technology. </p>
</tp:docstring>
</tp:member>
</tp:docstring>
<tp:member type="u" tp:name="type">
<tp:docstring>
- < Identifies the type of the containing DeviceEvent.
+ Identifies the type of the containing DeviceEvent.
</tp:docstring>
</tp:member>
<tp:member type="i" tp:name="id">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< an identifier which identifies this event in the event stream.
+ <p>An identifier which identifies this event in the event stream.
On X Window systems this corresponds to the XEvent serial number.</p>
</tp:docstring>
</tp:member>
<tp:member type="n" tp:name="hw_code">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< a numeric code which is hardware and system-dependent, identifying the
+ <p>A numeric code which is hardware and system-dependent, identifying the
specific hardware button or key on the device for which the event has
occurred. On X Window systems, for global key notifications and for most
non-global key notifications as well, this code corresponds to the
XKeycode. For switch and button events it indicates the switch
or button number.
- @note
+ </p>
+ <p>
For technical reasons, this code may differ from the XKeycode
when generated by Java applications for consumption by non-global
key listeners. This is subject to change in future versions of the
- DeviceEventController implementation.</p>
+ DeviceEventController implementation.
+ </p>
</tp:docstring>
</tp:member>
<tp:member type="n" tp:name="modifiers">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< an unsigned short int consisting of zero or more of the following
+ <p>An unsigned short int consisting of zero or more of the following
values OR'ed together:
- \li \c 1<<::MODIFIER_SHIFT (=1, corresponds to Xlib's ShiftMask)
- \li \c 1<<::MODIFIER_SHIFTLOCK (=2, corresponds to Xlib's LockMask)
- \li \c 1<<::MODIFIER_CONTROL (=4, corresponds to Xlib's ControlMask)
- \li \c 1<<::MODIFIER_ALT (=8, corresponds to Xlib's Mod1Mask)
- \li \c 1<<::MODIFIER_META (=16, corresponds to Xlib's Mod2Mask)
- \li \c 1<<::MODIFIER_META2 (=32, corresponds to Xlib's Mod3Mask)
- \li \c 1<<::MODIFIER_META3 (=64, corresponds to Xlib's Mod4Mask)</p>
+ <ol>
+ <li><code>MODIFIER_SHIFT</code> (=1, corresponds to Xlib's ShiftMask)</li>
+ <li><code>MODIFIER_SHIFTLOCK</code> (=2, corresponds to Xlib's LockMask)</li>
+ <li><code>MODIFIER_CONTROL</code> (=4, corresponds to Xlib's ControlMask)</li>
+ <li><code>MODIFIER_ALT</code> (=8, corresponds to Xlib's Mod1Mask)</li>
+ <li><code>MODIFIER_META</code> (=16, corresponds to Xlib's Mod2Mask)</li>
+ <li><code>MODIFIER_META2</code> (=32, corresponds to Xlib's Mod3Mask)</li>
+ <li><code>MODIFIER_META3</code> (=64, corresponds to Xlib's Mod4Mask)</li>
+ </ol>
+ </p>
</tp:docstring>
</tp:member>
<tp:member type="i" tp:name="timestamp">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< an unsigned integer representing the time that the
+ <p>An unsigned integer representing the time that the
event occurred. On X Window systems this event is
a time in milliseconds from some arbitrary starting
point; it therefore has a cycle time of approximately
</tp:member>
<tp:member type="s" tp:name="event_string">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< A string representation of the event. If is_text is
- \c True, then this string represents the character or typographic
+ <p>A string representation of the event. If is_text is
+ <code>True</code>, then this string represents the character or typographic
sequence that would be received by a focussed text input field.
event_string is in general suitable for exposure to the
end-user for purposes of keyboard echo.</p>
</tp:member>
<tp:member type="b" tp:name="is_text">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>< \c True if the event results in the insertion of characters
+ <p><code>True</code> if the event results in the insertion of characters
into an input text buffer, or would do so if delivered to a focussed
- text input field. ¨Typographical¨ key events have this field set to
- \c True, whereas ¨control¨ key events generally do not.</p>
+ text input field. 'Typographical' key events have this field set to
+ <code>True</code>, whereas 'control' key events generally do not.</p>
</tp:docstring>
</tp:member>
</tp:struct>
<tp:struct name="KeyDefinition">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A structure which defines the identity of a key for which notifications
- are to be requested. The data in the members of a ::KeyDefinition are used to
+ are to be requested. The data in the members of a KeyDefinition are used to
determine which keyboard events 'match' the notification request filed by a client. </p>
- <p>@note Ordinarily a KeyDefinition specifies one and only one of the criteria below;
+ <p>Ordinarily a KeyDefinition specifies one and only one of the criteria below;
the result of using a KeyDefinition with multiple members defined as nonzero is
- undefined. </p>
+ undefined.</p>
- <p>@param keycode if nonzero, the numeric, system-dependent value corresponding to a
+ </tp:docstring>
+ <tp:member type="i" tp:name="keycode">
+ <tp:docstring>
+ If nonzero, the numeric, system-dependent value corresponding to a
physical key on the keyboard. Keycode values have no semantic meaning to the end-user,
and may depend on the user's hardware and operating environment. They therefore are
- rarely useful "as-is" to AT clients, unless the client has used operating system
+ rarely useful 'as-is' to AT clients, unless the client has used operating system
services to identify the hardward keycode associated with a particular key symbol.
Notifications for key events requested by keycode are less dependent on modifier state
- than \c keysym based notifications, but some hardware (notably many laptops) may generate
+ than <code>keysym</code> based notifications, but some hardware (notably many laptops) may generate
more than one keycode for the same physical key, depending on the state of physical
shift/modifier keys.
- @param keysym if nonzero, the numeric value corresponding to the X Keysym of the key for which
+ </tp:docstring>
+ </tp:member>
+ <tp:member type="i" tp:name="keysym">
+ <tp:docstring>
+ If nonzero, the numeric value corresponding to the X Keysym of the key for which
notification is requested. Note that the presence of active modifiers will affect
- whether notification for key events requested via "keysym" specification takes place,
+ whether notification for key events requested via 'keysym' specification takes place,
since the keysym depends on the modifier state for most keys.
- @param keystring if non-NULL, the string value of the inserted characters if the corresponding
- key event has ::KeyEvent:is_text set to \c True, or the string representing the
+ </tp:docstring>
+ </tp:member>
+ <tp:member type="s" tp:name="keystring">
+ <tp:docstring>
+ If non-NULL, the string value of the inserted characters if the corresponding
+ key event has KeyEvent:.is_text set to <code>True</code>, or the string representing the
'name' of the key. On X11 systems, the string 'name' of non-printing keysyms corresponds
- to the values in "keysymdef.h" as provided by Xlib, with the leading "XK_" stripped off.</p>
- </tp:docstring>
- <tp:member type="i" tp:name="keycode"/>
- <tp:member type="i" tp:name="keysym"/>
- <tp:member type="s" tp:name="keystring"/>
- <tp:member type="i" tp:name="unused"/>
+ to the values in 'keysymdef.h' as provided by Xlib, with the leading 'XK_'; stripped off.
+ </tp:docstring>
+ </tp:member>
</tp:struct>
<interface name="org.freedesktop.atspi.DeviceEventListener">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<arg direction="in" name="event" type="(uinnisb)" tp:type="DeviceEvent"/>
<arg direction="out" type="b" tp:type="boolean">
<tp:docstring>
- \c True if the recipient/consumer wishes to consume the event, i.e.prevent it from being delivered to the desktop, \c False if the event should continue to be delivered as normal.
+ <code>True</code> if the recipient/consumer wishes to consume the event, i.e.prevent it from being delivered to the desktop, <code>False</code> if the event should continue to be delivered as normal.
</tp:docstring>
</arg>
</method>
</tp:docstring>
<arg direction="in" name="listener" type="o" tp:type="DeviceEventListener">
<tp:docstring>
- a DeviceEventListener which will intercept key events.
+ A DeviceEventListener which will intercept key events.
</tp:docstring>
</arg>
<arg direction="in" name="keys" type="a(iisi)" tp:type="KeySet">
<tp:docstring>
- a KeySet indicating which keys to intercept, or KEYSET_ALL_KEYS.
+ A KeySet indicating which keys to intercept, or KEYSET_ALL_KEYS.
</tp:docstring>
</arg>
<arg direction="in" name="mask" type="u" tp:type="ControllerEventMask">
<tp:docstring>
- a ControllerEventMask filtering the intercepted key events.
+ A ControllerEventMask filtering the intercepted key events.
</tp:docstring>
</arg>
<arg direction="in" name="type" type="au" tp:type="KeyEventTypeSeq">
<tp:docstring>
- a KeyEventTypeSeq that may created by ORing event types together.
+ A KeyEventTypeSeq that may created by ORing event types together.
</tp:docstring>
</arg>
<arg direction="in" name="mode" type="(bbb)" tp:type="EventListenerMode">
<tp:docstring>
- an EventListenerMode indicating whether the listener should receive the events synchronously, potentially consuming them,or just be notified asynchronously of those events that havebeen generated.@note Some platforms have limited support for global, preemptive EventListenerMode.Such a registration may fail if another client already has priority for preemptiveaccess to one or more of the members of the KeySet. AT consumers have the optionof re-trying the request without the global flag, or without the preemptive flag,or of re-trying with a different KeySet. The best support for pre-emptiveglobal keyboard listeners is provided on platforms whose Xserver implementationprovides the XEvIE extension.
+ An EventListenerMode indicating whether the listener should receive the events synchronously, potentially consuming them,or just be notified asynchronously of those events that havebeen generated.
+
+ Some platforms have limited support for global, preemptive EventListenerMode.Such a registration may fail if another client already has priority for preemptiveaccess to one or more of the members of the KeySet. AT consumers have the optionof re-trying the request without the global flag, or without the preemptive flag,or of re-trying with a different KeySet. The best support for pre-emptiveglobal keyboard listeners is provided on platforms whose Xserver implementationprovides the XEvIE extension.
</tp:docstring>
</arg>
<arg direction="out" type="b" tp:type="boolean">
<tp:docstring>
- \c True if the DeviceEventListener was successfully registeredfor the requested KeySet, ControllerEventMask, event types, and EventListenerMode; otherwise returns \c False.
+ <code>True</code> if the DeviceEventListener was successfully registeredfor the requested KeySet, ControllerEventMask, event types, and EventListenerMode; otherwise returns <code>False</code>.
</tp:docstring>
</arg>
</method>
</tp:docstring>
<arg direction="in" name="listener" type="o" tp:type="DeviceEventListener">
<tp:docstring>
- a DeviceEventListener which will intercept key events.
+ A DeviceEventListener which will intercept key events.
</tp:docstring>
</arg>
<arg direction="in" name="keys" type="a(iisi)" tp:type="KeySet">
<tp:docstring>
- a KeySet indicating which keys to intercept, or KEYSET_ALL_KEYS.
+ A KeySet indicating which keys to intercept, or KEYSET_ALL_KEYS.
</tp:docstring>
</arg>
<arg direction="in" name="mask" type="u" tp:type="ControllerEventMask">
<tp:docstring>
- a ControllerEventMask filtering the intercepted key events.
+ A ControllerEventMask filtering the intercepted key events.
</tp:docstring>
</arg>
<arg direction="in" name="type" type="au" tp:type="KeyEventTypeSeq">
<tp:docstring>
- an EventType mask that may created by ORing event types together.
+ An EventType mask that may created by ORing event types together.
</tp:docstring>
</arg>
</method>
</tp:docstring>
<arg direction="in" name="listener" type="o" tp:type="DeviceEventListener">
<tp:docstring>
- a DeviceEventListener which will intercept events.
+ A DeviceEventListener which will intercept events.
</tp:docstring>
</arg>
<arg direction="in" name="types" type="u" tp:type="EventTypeSeq">
<tp:docstring>
- an EventTypeSeq indicating which event types to listen for.
+ An EventTypeSeq indicating which event types to listen for.
</tp:docstring>
</arg>
<arg direction="out" type="b" tp:type="boolean">
<tp:docstring>
- \c True if successful, \c False if not
+ <code>True</code> if successful, <code>False</code> if not
</tp:docstring>
</arg>
</method>
</arg>
<arg direction="in" name="types" type="u" tp:type="EventTypeSeq">
<tp:docstring>
- an EventTypeSeq indicating which event types to stoplistening for.
+ An EventTypeSeq indicating which event types to stoplistening for.
</tp:docstring>
</arg>
</method>
<p>Notify the Registry instance that a device event has taken place, and
allow pre-emptive listeners the opportunity to 'consume' the event
and thus prevent its further issuance/forwarding. This is the
- method used by accessibility bridges to forward "toolkit dependent"
- device events to the Registry from the application's process space. </p>
+ method used by accessibility bridges to forward 'toolkit dependent'
+ device events to the Registry from the application's process space.</p>
- <p>@note AT clients do not normally need to use this method, it is intended for use
- by toolkit bridges and special-purpose applications. </p>
+ <p>AT clients do not normally need to use this method, it is intended for use
+ by toolkit bridges and special-purpose applications.</p>
</tp:docstring>
<arg direction="in" name="event" type="(uinnisb)" tp:type="DeviceEvent"/>
<arg direction="out" type="b" tp:type="boolean">
<tp:docstring>
- \c True if the event was consumed by a (pre-emptive) listener,\c False if not (in which case the device event will be forwardedas normal to any application which would normally receive it, e.g.the currently active application in the case of mouse or keyboard events).
+ <code>True</code> if the event was consumed by a (pre-emptive) listener, <code>False</code> if not (in which case the device event will be forwardedas normal to any application which would normally receive it, e.g.the currently active application in the case of mouse or keyboard events).
</tp:docstring>
</arg>
</method>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Notify the Registry instance that a device event has taken place in
an asynchronous manner. This is the
- method used by accessibility bridges to forward "toolkit dependent"
+ method used by accessibility bridges to forward 'toolkit dependent'
device events to the Registry from the application's process space.
If the event in question is potentially pre-emptible.
- ::notifyListenersSync should be used instead. </p>
+ notifyListenersSync should be used instead.</p>
- <p>@note AT clients do not normally need to use this method, it is intended for use
+ <p>AT clients do not normally need to use this method, it is intended for use
by toolkit bridges and special-purpose applications.</p>
</tp:docstring>
<arg direction="in" name="event" type="(uinnisb)" tp:type="DeviceEvent"/>
</tp:docstring>
<arg direction="in" name="keycode" type="i">
<tp:docstring>
- a long integer indicating the keycode ofthe keypress to be synthesized.
+ A long integer indicating the keycode ofthe keypress to be synthesized.
</tp:docstring>
</arg>
<arg direction="in" name="keystring" type="s">
<tp:docstring>
- an optional UTF-8 string indicating a complexkeyboard input event.
+ An optional UTF-8 string indicating a complexkeyboard input event.
</tp:docstring>
</arg>
<arg direction="in" name="type" type="u" tp:type="KeySynthType">
<tp:docstring>
- a KeySynthType indicating the type of event(s) to be synthesized: a key press, release, press-release pair,or a complex input string (for instance from aninternationalized or complex text input method, ora composed character).@note keycode may be truncated before beingprocessed, as keycode length may be platform-dependentand keycode ranges are generally much smaller thanCORBA_long. One or the other of keycode or keystring are generally NULL, (but not both), depending on the value of \c type.
+ <p>A KeySynthType indicating the type of event(s) to be synthesized: a key press, release, press-release pair,or a complex input string (for instance from aninternationalized or complex text input method, ora composed character).</p>
+
+ <p>Keycode may be truncated before beingprocessed, as keycode length may be platform-dependentand keycode ranges are generally much smaller thanCORBA_long. One or the other of keycode or keystring are generally NULL, (but not both), depending on the value of <code>type</code>.</p>
</tp:docstring>
</arg>
</method>
</tp:docstring>
<arg direction="in" name="x" type="i">
<tp:docstring>
- a long integer indicating the screen x coord for the mouse event.
+ A long integer indicating the screen x coord for the mouse event.
</tp:docstring>
</arg>
<arg direction="in" name="y" type="i">
<tp:docstring>
- a long integer indicating the screen y coord for the mouse event.
+ A long integer indicating the screen y coord for the mouse event.
</tp:docstring>
</arg>
<arg direction="in" name="eventName" type="s">
<tp:docstring>
- a string indicating the type of mouse event, e.g. "button1up"
+ A string indicating the type of mouse event, e.g. 'button1up'.
</tp:docstring>
</arg>
</method>
projects / platform / core / uifw / at-spi2-atk.git / blobdiff