Human interface abstractions such as the
popular
cursor are meant to
give guidance and aid to the users of programs and dictate how they
communicate back with the program. Abstractions can hold state
and by default have a basic selection functionality. Abstraction
authors can choose to support any number or type of human interface
devices to accept input from. This allows the benefits of new and
innovative input devices to be transparently and instantly leveraged
onto all programs that use Abstractions that have been updated to take
advantage of the new devices. This also allows for a certain
level of backwards compatibility in the event that the ideal device is
not present. One example of this is a program that uses a cursor
abstraction. The most ideal device to hook up to a cursor
Abstraction is currently a mouse and so when the program requests the
use of a cursor the cursor Abstraction object sees that a mouse is
attached
and assigns itself to the mouse. However, during the execution of
the program the mouse gets unplugged and taken away. At this
point the cursor abstraction sees that the mouse is no longer attached
and starts looking for another device to assign itself to. First
it hopes to find another mouse but if there are no other mice present
to attach itself to, it will then settle for the next best device as
dictated by its own defined priorities. It sees that there is a
keyboard attached to the system and assigns itself to the
keyboard. From that point the cursor is moved by the user
pressing the arrow keys and clicking is handled through other key
presses. Although a keyboard is not a very good way to control a cursor
it is better than not having anything at all. Suppose then that a
mouse was brought back and plugged into the computer. The cursor
Abstraction would now be given the opportunity to upgrade itself given
that there is now a more suitable human interface device available for
usage. This all happens behind the program's back seamlessly and it has
no idea what has transpired because it only interacts with the cursor
Abstraction object itself and not the devices that the Abstraction
object is using for input.
When the user creates input with a
device its
corresponding HInterface
delivers raw device events to all Abstractions that have assigned
themselves to it. That input is then translated into events in
the context of the Abstraction. Each Abstraction then takes all
of the EventReceptors that have been attached to it and performs
evaluation
processes to determine which EventReceptors have been triggered if
any. The corresponding callbacks assigned to the
EventReceptors that fired are then called.
Human interface abstractions such as the popular cursor are meant to give guidance and aid to the users of programs and dictate how they communicate back with the program. Abstractions can hold state and by default have a basic selection functionality. Abstraction authors can choose to support any number or type of human interface devices to accept input from. This allows the benefits of new and innovative input devices to be transparently and instantly leveraged onto all programs that use Abstractions that have been updated to take advantage of the new devices. This also allows for a certain level of backwards compatibility in the event that the ideal device is not present. One example of this is a program that uses a cursor abstraction. The most ideal device to hook up to a cursor Abstraction is currently a mouse and so when the program requests the use of a cursor the cursor Abstraction object sees that a mouse is attached and assigns itself to the mouse. However, during the execution of the program the mouse gets unplugged and taken away. At this point the cursor abstraction sees that the mouse is no longer attached and starts looking for another device to assign itself to. First it hopes to find another mouse but if there are no other mice present to attach itself to, it will then settle for the next best device as dictated by its own defined priorities. It sees that there is a keyboard attached to the system and assigns itself to the keyboard. From that point the cursor is moved by the user pressing the arrow keys and clicking is handled through other key presses. Although a keyboard is not a very good way to control a cursor it is better than not having anything at all. Suppose then that a mouse was brought back and plugged into the computer. The cursor Abstraction would now be given the opportunity to upgrade itself given that there is now a more suitable human interface device available for usage. This all happens behind the program's back seamlessly and it has no idea what has transpired because it only interacts with the cursor Abstraction object itself and not the devices that the Abstraction object is using for input.
When the user creates input with a device its corresponding HInterface delivers raw device events to all Abstractions that have assigned themselves to it. That input is then translated into events in the context of the Abstraction. Each Abstraction then takes all of the EventReceptors that have been attached to it and performs evaluation processes to determine which EventReceptors have been triggered if any. The corresponding callbacks assigned to the EventReceptors that fired are then called.