This is the OLD version of the course -- please see the
Spring, 2013 version
Homework 5: Create some Widgets using your system
18% of grade. Wed, Apr 15, 2009 - Fri, May 1, 2009
Note: For the this assignment, the late penalties will increase
every day (since I have to get the final grade submitted). Thus, turning
the final assignment in on May 2 will be -10, on May 3 will be -20, on May
4: -30 and so on.
For the final assignment (and
any HW4s that are really late), I decided to be generous, and extend the
deadline to be May 10 at midnight, then penalties will start to accrue every
day. I have to submit your final grades by May 14. (For HW4, the -40 point
penalty for being late will apply for homeworks turned in on or before May
10).
The goal of this assignment is to add some widgets to your
growing toolkit. Requirements include:
- The widgets you create must use your retained object model, your input
model, and your constraint system. For example, buttons should be constructed
out of rectangle and string objects from the retained object model, held
together with constraints, and the user interaction with the buttons should be handled
by a Selection interactor or equivalent.
- Widgets to be created must include:
- A button panel, which is basically a fixed menu or
palette. The user can press a button to perform an action. The interaction
should be NOT first-only (i.e., the user can press on one item and move to
another before releasing). A parameter to the button panel should determine
whether there is final feedback or not, i.e., whether the final selection
remains selected after you release the mouse, or not. If final selection is
shown, then the user should be able to pick the type of selection:
SINGLE, TOGGLE, or MULTIPLE. The manner for feedback (how the interim and
final feedback is shown) is up to you.
- A check-box panel, which is a set of check boxes. The interaction
should be first-only (i.e., the user cannot press on one item and move to
another before releasing). The "check" in the box can be presented as a
picture (image), a checkmark in a font, an "X" created with 2 lines,
or anything you want. The
final selection should always be visible. The selection type should always be
MULTIPLE.
- A radio-button panel, which is a set of radio buttons. The
interaction should be first-only (i.e., the user cannot press on one item and
move to another before releasing). The "dot" in the box can be presented as a
picture (image), a dot in a font, a filled-in circle or square, or anything
you want. The
final selection should always be visible. The selection type should always be
SINGLE.
- A number slider, for selecting a number in a range. You can do
either a horizontal or vertical slider (you do not have
to do both). The slider should accept a minimum and maximum value and standard
increment value (defaults: 0.0 to 100.0, and 10.0). There must be some kind of
graphical indicator to show the current value, and which can be dragged with
the mouse to change the value. There should also be arrows at either end of
the slider to increment and decrement the value by the standard increment.
Extra credit for providing "paging" by clicking on either side of the
indicator (in the "trough") to increment or decrement by bigger amounts. You
do not need to support auto-repeating by holding the mouse button down
over the arrows or in the trough. The appearance of the slider is up to you;
it might look like a scroll bar or a slider in other widget sets.
- A selection handles widget for selecting, moving and resizing
graphical objects. (Many of you might have this part already working
from assignment 3.) It should be possible to add the selection handles widget
to an application and automatically have all the graphical objects in a group
be selectable without any additional code. The handles should be attached to
the graphical object with constraints, so if the object changes size or moves
while selected, the handles will still be in-place. (Alternatively, if you
made it possible for the programmer to make arbitrary graphical objects
selectable with handles, including groups, that is OK too.) Your selection
handles should support:
- Selecting a single object by clicking on it.
- Causing no object to be selected by clicking in the background.
- Moving the selected object by clicking and dragging on it.
- Optional: Resizing the selected object by pressing and dragging on a handle of the
selection handle widget. If you implement it for simple graphical objects
(rectangles and lines), that will be sufficient to get extra credit.
- It is not necessary to support selection of multiple
objects, selecting all objects in a dragged-out region, or moving or resizing
multiple objects.
- The button panel, check-box panel, and radio-button panel should take the
same layout parameters as LayoutGroup: layout and offset, to control
how the items are laid out.
- The labels shown for each item for the button panel, check-box
panel, and radio-button panel should be able to be strings or arbitrary
GraphicalObjects, including groups. This could be made convenient to the
programmer for example by having two forms of the addChild method that adds
new items to the panels: one that takes a GraphicalObject and one that takes a
Java String object.
- Each widget should provide its current value in a value variable,
that other objects can have constraints to.
- Each widget should have a way of calling a call-back procedure when
the user changes the value of the widget. This might be implemented by taking
an object on which a standard method is called, as in standard Java Swing
widgets. The callback for the panels should be provided with the current value
of the widget (i.e., which panel item is selected). Note that since the label
is not necessarily a string, the call-back may be passed a graphical object as
the current item. The number slider should pass the current number value to
its call-back. The call-back for the selection handles should be called
whenever the selection changes, and should be passed the object that is
selected, or NULL if objects became deselected.
- Hitting ESC should abort the widget while it is in progress. (This should
come for free from your implementation of input handling.)
- Note that you are not being asked to create any widgets that pop up:
no pull-down menus, no option menus, etc. These require that the toolkit
support creating special kinds of windows and having your interactions work
across multiple windows, which requires a lot of special and tricky
programming.
- Extra credit for other parameters for these widgets, or other kinds of
widgets created.
As always, we may end up refining this design as you work on the
assignment.
Test Program
Please create a test program that shows off all the features of your widgets.
It should include examples of widgets with different layouts, different numbers
and types of items as the labels (text and graphics), different selection
parameters for the button panels, etc. Have a constraint that ties the string of
text objects to the value of each of the widgets. (Note that doing type
conversions in this call-back is fine, since the call-back may be passed a
non-string.) Have call-backs that print out the values passed to the call-back
procedure. Thus, after any widget is operated, a text string on the screen
should change, and message should be printed in the test window's console.
I will probably edit this program to try out other options, so add comments for
any non-obvious parts of the design.
Node-and-Edge Editor
You will modify the node-and-edge editor from homework 4 to use all the
widgets you create. You can think about different ways to use the widgets. For
example, a button panel might control the global mode (selecting or drawing
lines or nodes), a radio-button panel might control colors, and checkboxes might
be for whether the object is filled or not. The number slider might control the
line border width. The selection handles might allow selection of the nodes. If
you allow selection of the edges, then be sure to handle moving the edges
correctly. It would be good to be able to delete the selected node.
Read-Me File
Be sure to turn in a read-me file that describes (1) what files to execute for test program or
programs, and the node-and-edge editor, (2) anything interesting about your
design, including anything you did for extra credit, and (3) anything
non-obvious for how I can edit the test program to try out different options and
different call-back procedures.
Back to Homework Overview
Back to 05-830 main page