05-830, User Interface Software, Spring, 2013

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:

1. The Garnet-Amulet "Interactor" model, which might better be called a "behavior object" model.
2. The SubArctic model, with multiple levels of "focus policies" and "dispatch agents".
3. 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.

Requirements

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 code.
• 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 in subArctic.
• 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).

Drawing Editor

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 drawing area.

Extra Credit

For extra credit, you can implement more selectable objects, more behaviors, or more features in your drawing editor. Here are some ideas.

Selectable objects:

• SelectableImage: displays one of four images depending on whether it is selected, interim-selected, both, or neither.

Interactors:

• 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.

Events

• 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.

As always, we will probably end up refining this design as you work on the assignment.

Back to Homework Overview
Back to 05-830 main page