This is an old version of the class. Please see the 2020 version instead.

05-830, User Interface Software, Spring, 2017

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:

  1. If you decide to create some widgets, then here are the requirements:
    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 Choice Behavior.
    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. 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.
      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. It should use your Move Behavior object for dragging the indicator, and the Choice Behavior for detecting the tapping on the arrows.
      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, 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.
    7. 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.)
    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.
    10. 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.
    11. 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.
  2. 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:
    1. 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.
    2. 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