GUI Programming Project 4 - Extending the Draw Program

CMSC 437
Graphical User Interface Programming

TUE,THU 5:30-6:45 PM ACIV 015
Spring 1997

Project 4: Extending the Draw Program

Date Due Tuesday, May 15, 1997 before midnight.

Errata and additions are listed at the end of this page, including changes from the description given in class!

Purpose

To gain experience using menus and dialogs, designing and implementing a graphical modeling hierarchy, and putting UI design principles into practice.

Assignment

For this project, you will continue to refine the drawing editor application you developed in Project 3. In particular, you will extend the interface, convert the single-level display list to a full graphical hierarchy, and add further direct manipulation capabilities to the graphical shapes.

For this project, we are taking a slightly different approach in the specification. Instead of dictating exactly how each feature must operate, we are requiring that your program exhibit certain features, but most of the details of the interface are up to you. This will give you the chance to explore and justify design decisions that affect the usability of your project. Here are the particular features you must implement, in addition to the functionality of Project 3:

Shape Resizing

In addition to being able to move individual shapes, you will add resizing capability to shapes that have been selected. Grabbing a control point of a selected shape and dragging it with the mouse will cause the dimensions of the shape to be changed accordingly.

Grouping

You will add the ability to group objects. Multiple objects may be selected, and then grouped together. These groups may then be moved, but need not be resizable or allow other shape properties to be modified. This will extend our display list to a full graphics hierarchy, since groups can also be grouped! The user should also be able to "Ungroup" groups.

One way to approach this is to add a new type of node, called a container or group node. A container node, analogous to a Manager widget in Motif or a Java component descended from Container, is a node which can contain other nodes. Like other nodes in the display list, it responds to messages such as 'draw' or 'select'. Initially, all created shapes are top-level nodes in the display list. Selecting more than one shape and issuing the "Group" command will cause the shapes to be collected under one container node, which is displayed by showing the control points of its collective bounding box. An "Ungroup" command breaks its contained nodes up and puts them back into the container's level in the hierarchy.

When a set of selected objects are grouped, the shapes should retain their relative ordering previous to the group command. For example, if there are shapes 1-10 on the display list, and you group shapes 2, 4, and 7, then the group containing 2, 4, and 7 (in that order) will be placed in the display list. "Ungrouping" will place the members of the group in order into the display list where the group was.

Groups are truly hierarchical. If I have a group and a single shape, and I group those together into a new group, ungrouping the new group will produce the old group and shape.

Layering Control.

Any selected shape or group will be able to be moved to the top or bottom of the top-level display list. The behavior of this operation is only defined for a single selection, not for multiple selections.

Selecting, Deleting.

You will add "Select All" and "Deselect All" commands. These will cause the top-level display list to be traversed, selecting or deselecting each shape or group accordingly. The "Delete" command, as in the previous project, will cause the currently selected objects to be removed from the top-level display list.

Fill as an Attribute

You need to be able to change whether shapes are filled or not. This should be analogous to changing color attributes or line-width attributes of a shape.

Clear, Quit.

The "Clear" command now has a different functionality than in Project 3; Clear will now simply delete all objects out of the display list. What we formerly called the "Clear color" will now be called the "Background color"; changing the Background color will cause the background of the drawing to change immediately, without erasing the objects in the drawing.

The quit button will now produce a dialog box, asking whether the user really wants to quit or not.

In this project, we will allow a great deal of freedom in the design of the interface and the project as a whole. Because of this, you should apply the concepts discussed in the lectures on Interface Design during your development. You should make interface decisions after careful consideration, not simply because something may be easier to implement or what we have in an existing system! However, we are requiring the following interface features:

Menu Bar

Your program should include a menu bar with pull-down menus. In Motif, the easiest way to do this is by using a XmMainWindow manager under the top-level shell widget. In Java, a Frame allows a menu bar to be added.

You should add as many commands to the menus as you can, but your primary concerns should be ease-of-use and interface "elegance". "Session" commands such as quitting, and editing commands such as grouping, layering, and deleting are good candidates for menus. Remember to apply concepts of menus discussed in class as you design.

Dialog Boxes

Your program must include at least one dialog box; when the user quits the application, it should pop up a dialog asking if s/he really wishes to do so, and allowing him/her to cancel. You may use dialog boxes in other areas of the project as you deem appropriate. One good candidate might be for clearing the drawing. Remember that operations placed in a dialog box take a little longer to work through for the user, and thus should be special, infrequent operations.

Documentation

Yes, documentation is part of what makes up an interface! You must also submit documentation, along with your project, taking the form of a User's Guide. This documentation should be enough for any undergraduate student to read and understand how to use your software. It should include instructions on how to access and use all features of your project, but in a style which teaches me how to use your software (i.e., not an alphabetized list of commands and descriptions). This documentation will be instrumental in aiding the grader and/or instructors in evaluating your project!

Undo

Undo is not required, but if you implemented it in Project 3, it is recommended that you continue to extend it for this project.

Extra Credit

Options for extra credit may be found here, along with appropriate explanation and guidelines.

Hints

Making sure you have a good DynamicArray or LinkedList class will be a big help. Whatever its underlying implementation, it should support such operations as: add to bottom, add to top, remove, and delete, as well as ways of traversing it in both directions. Using a List of references or pointers to objects will make all your operations simpler.

The group, or container class should have a "draw" method defined on it and maintain its own list of contained objects. In this way, a group is just a special kind of shape. Think of groups as a "recursive" shape.

Resizing should be fairly straightforward if you implement control points as Rectangle objects.

Optionally, you might add a "Save" command which would simply print out a text representation of the current graphics hierarchy to the standard output. The format of the representation isn't important, as long as it contains all the important information in the hierarchy. This might help in debugging your hierarchy, and would be a good hook for a "real" save command!

Errata

Friday, 18 April: After introducing the project in class, we decided to remove some of the project requirements. Line width and saving are no longer required features.