[MSOE Homepage]

Dr. Taylor's MSOE Homepage

Courses

Unix is a Four
Letter Word

My Photo Album

My Personal Homepage

CS-321 Main page

CS-321 Lab 3: Graphics Shell

Fall Quarter 1999



Electrical Engineering and Computer Science Department
Dr. Christopher C. Taylor

S-331, 277-7339

www.msoe.edu/~taylor/

Acknowledgment

This lab was originally developed by Dr. Henry L. Welch.

Purpose

Become familiar with the graphics shell software written for CS321 development projects.

Overview

To simplify development of graphical programs and to provide a more robust and uniform interface for products a specialized graphical shell has been developed for CS321. It uses Motif and the X Window System to provide a simple graphical user interface (GUI) with a drawing area, buttons, menu, and command line. Your project WILL BE REQUIRED to work within this shell.

The source files for the shell are located on torres in /usr/local/include/cs321/. To use the shell the only files you need in your own directories are the Makefile and cs321.cpp. You should also copy Cs321 to your home directory. After copying these files use the Makefile (type: make cs321) to build the shell and then run it. Become familiar with the various features of the GUI shell and note that it simply generates event driven call backs which do little more than cout before returning. (i.e., There is no functionality yet.)

Assignment

You are to derive a class from the Shell class to add some functionality that supports the drawing of white pixels on the black background of the drawing area. As a minimum you will need to link in your container and shape class work (NOTE: you will find it necessary to update some of this previous work) and override the following virtual functions of Shell:

  • Help_Text - to document your command line syntax and mouse usage
  • Cmd_Parse - to parse the command line
  • Draw - the real workhorse (see below)
  • The constructors and destructors as appropriate

Draw is activated whenever any event occurs in the drawing window. This includes button presses and motions of the mouse, resizing, and exposures (when any part of the window is suddenly uncovered). When the drawing window is initially created by the GUI shell it will automatically generate an exposure event. For the present, ignore the resize event. When an exposure event occurs simply redraw all the points in your container using XDrawPoint. (For more efficient code you should really look at the count field of the XExposeEvent and only redraw when this is 0.) When a button press occurs (actually press or release, your choice) you will have to access the XEvent to determine the mouse information contained therein. (See the Events section of The Definitive Guide to the X Window System Vol. 2 for details of this structure.) After determining the mouse location add that point to your container and draw it.

Upon referencing XDrawPoint you will find that you need three things in addition to the x and y coordinates of the pixel. These are the Display, the Drawable, and a GC (graphics context). The first two are protected members of the Shell class that know where to find the drawing window. The graphics context contains all the information about how to draw the object (e.g. color, etc...). You will need to create a GC the first time Draw is called (don't forget to free it using XFreeGC in your destructor). The following code will generate a simple GC for white pixels.


Display   *display; // From Shell class
Drawable  drawable; // Don't include in your code
Screen    *screen;  // Presented here for clarity

XGCValues val;
GC        gc;      // This may be more appropriate
                   //  as a class member

val.foreground = WhitePixelOfScreen(screen);
val.background = BlackPixelOfScreen(screen);
gc = XCreateGC(display,drawable,
        GCForeground|GCBackground,&val);

You may also find it useful to include the following files:

  • #include <X11/Xlib.h>
  • #include <X11/Xutil.h>
  • #include <Xm/Xm.h>

I will be more than happy to consult with you on an individual basis, but I have purposely left some of the details for you to research.

Lab report (due 4:30pm, October 6, 1999)

The lab reports should be self-contained. That is, it should be possible for someone to understand what you did and why without seeing anything other than your report and any previous reports that you have submitted. Your report should include:

  • Purpose
  • Problem Statement
  • Procedure -- what approach you used to solve the problem
  • Documented source code (clearly identifying any changes made since your last submission)
    You may wish to use gensrc, a shell script which will produce one file containing all of your source code files and Makefile with the markup commands required by my electronic submission procedure.
  • Discussion including:
    • A tally of the number of new Non-commented Lines Of Code (NLOC) written for this lab assignment. You may use the CLC perl script on your code. If possible, break the NLOC down into the various features you needed to implement.
    • A summary of your activity log indicating how much time you spent on each phase of the assignment.
    • A narrative describing any specific problems you encountered and how you solved them.
  • Conclusions (what you learned, suggestions of how the lab could be improved, things you would have done differently, etc.)

As with any report you submit, correct spelling and grammar are required. In addition, your report should be submitted electronically following the Electronic Submission Guidelines. (You may wish to consult the sample report before submitting your report.) Be sure to keep copies of all your files, in case something gets lost. It may be wise to keep a diskette backup as well.

If you have any questions, consult the instructor.


This page was created by Dr. Christopher C. Taylor.