Assigned: Monday, March 2, 2020,
Due: Wednesday, 3/18/2020 - extended until Monday, 3/23/2020 Wednesday, 3/25/2020 at 1:30pm.
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 and most difficult parts of
toolkits, so you will be implementing the Garnet-Amulet "Interactor" model, which might better be
called a "behavior object" model.
(NOTE: You are allowed to use a different input model if you want to design a new one. Please discuss this with the professor.)
Requirements
The requirements for your implementation include:
- Provide reusable input handling so objects can be made interactive with very few lines of
code.
- The interactive behaviors must be parameterizable to support a wide variety of behaviors with a small number of objects.
- The use of the behavior objects should be generally OS independent - that is, all the dependencies on the machine or even the underlying Java or JavaScript 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 language 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:
- 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).
- You need to support the various keyboard modifier keys, like SHIFT, CONTROL, ALT, etc.
- The default start event is left mouse button down.
- The stop event will also be settable in the same way. The default
stop event is left mouse button up.
- 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. 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, or MULTIPLE. SINGLE selects the clicked object and de-selects all other objects in the group (exactly 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.
- 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).
Extra Credit
For extra credit, you can implement specialized selectable objects, more behaviors, or more parameters to your behavior objects.
Here are some ideas.
Selectable objects:
- SelectableImage: displays one of four images depending on
whether it is selected, interim-selected, both, or neither.
Interactors:
- 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.
- Hover state can be supported for Choice Behaviors, for when the mouse just moves over the target objects.
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.
Readme file
Please include a readme file in .doc, .txt or .pdf format (note: not .md format) that explains how your behavior system works and how to use it. This document must describe:
- How behaviors are integrated into your system.
- A programming guide that documents for a user of your API how to create and attach your behavior objects to a graphical object.
I anticipate that this will only take a page or two, so it shouldn't be a big time sink.
Detailed Specifications
If you have questions about this homework, it is best to post them on the class Piazza page, and then I will answer the questions for everyone. Be sure to mention which language you are using.
There are two versions of the specifications for this homework - one in Java and one in JavaScript. They should be approximately identical, but you should use the one for the language you are using. Note you need to use the same language for all of homeworks 2 through 5.
Back to Homework Overview
Back to 05-830 main page