05-830, User Interface Software, Spring, 2009

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:

  1. 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.
  2. Widgets to be created must include:
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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:
      1. Selecting a single object by clicking on it.
      2. Causing no object to be selected by clicking in the background.
      3. Moving the selected object by clicking and dragging on it.
      4. 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.
      5. It is not necessary to support selection of multiple objects, selecting all objects in a dragged-out region, or moving or resizing multiple objects.
  3. 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.
  4. 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.
  5. Each widget should provide its current value in a value variable, that other objects can have constraints to.
  6. 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.
  7. Hitting ESC should abort the widget while it is in progress. (This should come for free from your implementation of input handling.)
  8. 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.
  9. 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