The ATK interface provided by UI components
which the user can activate/interact with.
#AtkAction should be implemented by instances of #AtkObject classes
with which the user can interact directly, i.e. buttons,
checkboxes, scrollbars, e.g. components which are not "passive"
providers of UI information.
Exceptions: when the user interaction is already covered by another
appropriate interface such as #AtkEditableText (insert/delete text,
etc.) or #AtkValue (set value) then these actions should not be
exposed by #AtkAction as well.
Though most UI interactions on components should be invocable via
keyboard as well as mouse, there will generally be a close mapping
between "mouse actions" that are possible on a component and the
AtkActions. Where mouse and keyboard actions are redundant in
effect, #AtkAction should expose only one action rather than
exposing redundant actions if possible. By convention we have been
using "mouse centric" terminology for #AtkAction names.
The ATK interface provided by UI components which the user can activate/interact with.
#AtkAction should be implemented by instances of #AtkObject classes with which the user can interact directly, i.e. buttons, checkboxes, scrollbars, e.g. components which are not "passive" providers of UI information.
Exceptions: when the user interaction is already covered by another appropriate interface such as #AtkEditableText (insert/delete text, etc.) or #AtkValue (set value) then these actions should not be exposed by #AtkAction as well.
Though most UI interactions on components should be invocable via keyboard as well as mouse, there will generally be a close mapping between "mouse actions" that are possible on a component and the AtkActions. Where mouse and keyboard actions are redundant in effect, #AtkAction should expose only one action rather than exposing redundant actions if possible. By convention we have been using "mouse centric" terminology for #AtkAction names.