This is an old version of the class. Please see the 2017 version instead.
Homework 3: Design and Implement an Input Model for your Retained Object System
18% of grade. Tuesday, Feb. 12, 2013 -
Tuesday, Mar. 5, 2013 extended to: Tuesday, Mar. 19, 2013
The goal of this assignment is to add input handling to your retained
object model. This will allow the mouse the be used to manipulate the graphical
objects. As discussed in lecture, input is one of the least-researched parts of
toolkits, and there are basically only three models to choose from. It would be
neat if you invented a new one (it might even be a research contribution worthy
of publication). The models are:
- The Garnet-Amulet "Interactor" model, which might better be
called a "behavior object" model.
- The SubArctic model, with multiple levels of "focus policies"
and "dispatch agents".
- The Java model (also used in Visual Basic, etc.), where each individual
graphical object has to directly handle all relevant input events (mouse
down, up, etc.)
For this assignment, you are expected to use the first one, #1. (If you have a strong reason for using a different one, you can discuss this with the professor.) For #1, I provide
an implementation guide on a design you might
use for Interactors to go with the Retained Object design used for assignment
#2. This design is in another file.
The requirements for your implementation include:
- Provide some way to have reusable input handling. This means that
your design must allow me to make objects interactive with very few lines of
- The interactive behaviors must be parameterizable in some way, either by
setting parameter on the behavior objects (like in Amulet interactors) or by
choosing which of a variety of behavior objects to attach to my objects like
- The use of the behavior objects should be generally OS independent - that is, all the dependencies on awt or Android should be limited into a small number of files. (An exception to this will be the event names -- it is OK to use the symbols provided by the OS for keyboard keys like F1, ESC, etc.)
- The behaviors that must be supported include:
- Moving objects with the mouse
- Selecting one or more of a set of objects
- Creating new objects
- Required parameterizations of the behaviors are as follows:
- Under Swing, all behaviors must allow the selection of which mouse button starts them,
including which modifiers (e.g, a behavior might start only when
the shift right mouse button goes down, or only on left mouse button down).
- Under Swing, you need to support the modifiers are defined in BehaviorEvent.java, and include the various keyboard modifier keys, like SHIFT, CONTROL, ALT, etc. Under Android, these can be ignored.
- The default start event is left mouse button down (which maps to touch-down on Android)
- The stop event will also be settable in the same way. The default
stop event is left mouse button up (which maps to touch up on Android).
- All behaviors must be abortable by hitting a key while the
interaction is in progress. You can make the particular abort key be
settable if you want. Good defaults would be the ESCAPE key for awt/Swing, and maybe some keycode like KEYCODE_F1 for Android (since Android uses ESC for the "back" action). Aborting an interaction should return the affected
objects to their original state before the interaction started. For example,
if a move-behavior is aborted, then the objects should be where they were
before the interaction started.
- All behaviors will have a parameter of a group to operate on.
The behavior will operate on immediate children of the group. For
example, if a moving behavior is attached to a group, then each immediate
child of the group will be moveable. The behavior will decide which object
in the group to operate on by seeing which immediate child of the group is
under the mouse when the start event happens.
- For moving objects, there are no additional required parameter.
- An optional additional parameter for moving is gridding. See below.
- For selecting objects, there are two additional required parameters:
- type of selection, which can be SINGLE, TOGGLE, or MULTIPLE. SINGLE selects the clicked object and de-selects all other objects in the group (exactly one
selection). TOGGLE toggles the selection of the clicked object and de-selects all other objects in the group (zero or one selection). MULTIPLE toggles the selection of the clicked object without changing any other objects (zero or more selections). To be clear:
- SINGLE: clicking on the object that is already selected does nothing (leaves it selected). Clicking on an object that is not selected causes that object to be selected, and makes sure no other objects are selected. Clicking inside the group but not
on any objects causes the selection to become empty.
- TOGGLE: clicking on the object that is already selected causes it to be un-selected, so there is nothing selected. Clicking on an object
that is not selected causes that object to be selected, and makes sure no other objects are selected. (One or zero selections).
Clicking inside the group but not on any objects causes the selection
to become empty.
- MULTIPLE: clicking on an object that is already selected causes it to be un-selected but does not affect any other objects. Clicking on an
object that is not selected causes it to be selected, but does not affect any other objects. Clicking
inside the group but not on any objects causes no change in
which objects are selected.
- firstOnly which controls whether the selection can move from
object-to-object during the interaction. If firstOnly is true, then only the object that was initially clicked can be selected or toggled
while running. To select a different object,
the user would have to restart the behavior by releasing the mouse and clicking on the other object. This corresponds to how push buttons,
radio buttons, and checkboxes work in most systems. If firstOnly is false, then the target object can be changed while the
behavior is running
by moving the mouse. This corresponds to the behavior of menus in most systems.
- Selection must support the
difference between interim-selection feedback while the behavior is
running, and final selection feedback when the behavior is finished.
There might be different feedback showing the interim and final states. For
example, this is how radio buttons and checkboxes work.
- For creating new objects, the only parameter is whether two
points or one point is needed to create the object. If one point, then the
new object is created immediately when the user presses (or whatever the
start event is). If two points, then the new object is created when the user
releases (or whatever the stop event is).
For the last part of the assignment, you will use your
GraphicalObjects and behavior objects to create a simple drawing editor.
The editor should have the following features, at a minimum:
- creating lines and rectangles of fixed color and thickness
- selecting a graphical object, with feedback showing which
object is selected
- moving graphical objects around
The user interface is up to you. Most drawing editors use a tool
palette to switch between creating lines and rectangles. You can do
this with Swing or Android components if you want, or you can create a trivial widget out of the behavior objects and graphics (but don't spend much time on it), or (under Swing) you can even just use
keyboard modifiers -- e.g., shift-drag to create lines, plain drag to
create rectangles. (Note that you will be making widgets for the last homework, so don't spend much time on creating widgets now). If it isn't obvious how to use your editor, be
sure to display Text objects that document it, preferably outside the
For extra credit, you can implement more selectable objects, more behaviors, or more features in your drawing editor.
Here are some ideas.
- SelectableImage: displays one of four images depending on
whether it is selected, interim-selected, both, or neither.
- NewImageInteractor: scales an image to fill the rectangle
dragged out by the user.
- GrowInteractor: resizes a graphical object. Requires adding a
resize() method to GraphicalObject.
- Grid size parameter for MoveInteractor, which constrains the
moving object to grid coordinates.
- Implement the Click and Drag events, as in Amulet. The DRAG event is only
raised when the mouse is pressed down and moved. Amulet saves
the object under the mouse at the time of the downpress and then waits to see if the mouse is moved. If it is moved, then the original object is noted with the DRAG
event. If the mouse is not moved, and a button up is seen, then the CLICK event is raised instead, again with the original object.
This makes it easier to implement the standard click and move behavior, so
that selection happens on left down (so the object always becomes selected), and the
moving starts on left-drag.
Drawing editor features:
- Changing line thickness and color of the NewLineInteractor (note that you will be making widgets for the last homework, so don't spend much time on creating widgets now).
- Changing line thickness and color of selected object
- More kinds of graphical objects
- Changing object's size.
See the detailed discussion for the design with
behavior objects for further ideas and information.
As always, we will probably end up refining this design as you work on the
(Last revision of this page: 2/8/2013)
Back to Homework Overview
Back to 05-830 main page