Please read the remarks about programming problems for this course.

This assignment is the first of three parts.

Cinder and Cairo provide the means for executing programs to draw pictures. They both use immediate mode graphics. The process is similar to drawing on a whiteboard—you can draw an image, but to move an image elsewhere on the board you must erase it and redraw it in its new location.

Another graphics paradigm uses structured graphics, which sometimes is referred to as the retained object model. This approach allows persistent objects to be moved, resized, duplicated, etc., without the applications developer manually erasing and redrawing images. Such structured graphics APIs allow developers to build applications that permit users to interact with software components through direct manipulation; for example, a user may be able to select a graphical object and move it within a window or make it bigger or smaller. All modern UIs permit such direct manipulation.

Your task is to develop such a direct manipulation 2D graphics API on top of Cinder and Cairo that provides a GraphicalObject abstract base class from which developers can derive concrete graphical objects for applications. GraphicalObject objects must support the following operations:

• Creation. A user or program must be able to create and add new application-specific graphical object instances to a window.
• Deletion. A user or program must be able to remove and clean up application-specific graphical object instances from a window.
• Selection. A user must be able to select an existing graphical object within its window. This could be a prerequisite for moving, resizing, etc. the object. Selection is best achieved by enabling graphical objects to receive mouse events.
• Moving. A user or an application must be able to reposition an object within its window. For user interaction, this typically is achieved by the user dragging the object with the pointing device. A particular subclass or instance may override this capability to enforce immobile objects, but this behavior is expected in general.
• Rendering. A graphical object should be able to draw itself within a window; this is achieved via a draw method or the like. Such a draw method will take advantage of Cinder/Cairo underlying immediate-mode graphics capabilities. The rendering method allows users to distinguish one graphical object from another within a window.
• Bounding area. A graphical object should be bound by a rectangular area, its bounding box. In general, no part of the object's visual presentation will appear outside of its bounding box, and the object will not receive mouse events that occur outside of its bounding box.

Provide a simple application that demonstrates the capabilities of your API. The application should allow the user to create several different kinds of graphical objects and manipulate them within a window. Examples include:

• A mathematical graph editor. The user can create and move around the graph's vertices. The user can connect vertices via edges (graphical lines). The user can edit the labels of the vertices. The user can save the resulting graph in an adjacency matrix on disk and load saved graphs for additional editing. The vertices in the restored graph should appear in the same locations within the window they were previously when the graph was last saved.
• A simple flowchart editor. The user can add symbols for decisions, processing, and I/O. The text within the symbols will consist of simple statements (processing nodes) or conditions (decision nodes). The flowchart symbols should expand and shrink as needed to accommodate the size of their enclosed text. After building the flowchart the application can save the corresponding program in the traditional, text-based format in a text file. The textual program should be in a simple language such as a subset of C++ or Python. The application also should be able to read in a simple textual program and generate a graphical flowchart.
• A simple graphical spreadsheet. The application presents a grid in which the user can type in numbers (displayed as graphical text). The user then can specify a range of values to sum or average by dragging across a range of adjacent grid cells. Allow the user to generate a line graph that visually displays the values in a range of cells.
• A two-player checkers game. A user can move (drag) a piece to a different square. The current player cannot move an opponent's piece. The application enforces legal moves, detects jumps and crownings, and determines when the game is over.

Your sample application does not need to be fancy or look polished or professional, but it does need to demonstrate sufficiently the capabilities of your graphical object API.

Important! The graphical objects in your example application must display some sort of interrelatedness; for example, moving a vertex in a graph should cause all edges connected to that vertex to move with it. In a graphical spreadsheet application, editing one of the values in a range should update the calculations for that range and redisplay the line graph that depends on that cell. This notion of changing things in the graphical presentation causing other things to change is an essential quality that Part 2 will address directly. Consider the Cinder Boost signals application we saw in class. Pressing the cursor keys causes the bar and dial to adjust accordingly. Note that in that example the dial object is a very crude graphical object (it can draw itself, but, for example, users cannot interactively move it). On the other hand, the progress bar is not a true graphical object at all— the progress bar is merely a visual artifact of the application's draw method.

When the assignment is due, be prepared to demonstrate your application in class and discuss the design of the API you developed to support your application. A slide or two illustrating your API's class hierarchy would be helpful.

After your presentation submit your source files to eclass.e.southern.edu.