This is an old version of the class. Please see the 2020 version instead.
Homework 5: Build an interesting UI or some widgets with your toolkit
18% of grade. Tuesday, April 4, 2017 -
Thursday,
May 4, 2017, 1:30pm
The goal of this assignment is to create some interesting system or else to add some widgets to your
growing toolkit. Requirements include:
- If you decide to create some widgets, then here are the requirements:
- 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 Choice Behavior.
- 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. However, it is not acceptable to use the "selection handles" from assignment 3 -- the choice behavior must be able to be generalized to be used for the button panel in addition to being used for selection handles.
- 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. It should use your Move Behavior object for dragging the indicator, and the Choice Behavior for detecting the tapping on the arrows.
- 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, where the "listener" pattern is used. 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 some key (ESC in Swing or some other key on Android) 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.
- 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.
- Alternatively, you can invent your own project that has equivalent difficulty to above. That is, it should have at least 5 major pieces (corresponding to the 5 kinds of widgets), and should take about 30 hours of time to build. Some ideas include:
- Recreating the previous assignments and the test harness (the testing programs like testframe.java) in a different environment, like Processing or JavaScript or Python, that might be used in a future version of this class.
- Creating a fairly large-scale application using your toolkit so far, such as an elaborate drawing program (like Illustrator or PowerPoint) or a prototyping program (like Axure.com or Balsamiq Mockups), etc.
Read-Me File
Be sure to turn in a read-me file that describes (1) what files to execute for me to test everything you did, (2) anything interesting about your
design, including anything you did for extra credit, and (3) anything
non-obvious for how I can edit the program(s) to try out different options.
Back to Homework Overview
Back to 05-830 main page