CSE 332S: Object Oriented Software Design Laboratory

Spring 2008: Lab 4

Due 11:59pm, March 25, 2008.

Purpose

This lab will give you some more experience with the design, implementation, and testing of C++ code. It will also introduce the use of a third-party library, and the design of a graphical user interface (GUI) in C++.

This lab will continue the development of an instant message client by getting you to write and test a graphical interface for your client.

Preparation

This assignment will use the Qt graphical toolkit from TrollTech. Qt is a multi-platform graphical interface toolkit, that is free for a number of uses. If you write your code correctly, it should work on Windows, Linux, and Mac systems with no modifications. To allow it to do this, the toolkit contains a number of abstractions for things that tend to differ between these systems, such as network communications and threading support. In this lab, we will only use the graphical elements of the toolkit, but will use others in subsequent labs.

Before you start this lab, you should browse through the Qt documentation to get a feel for what the toolkit can do. In particular, check out the How to Learn Qt page.

As in the previous lab, you should document all of your code with the doxygen documentation system.

Assignment

  1. Work your way through the first seven steps of the first tutorial on the Qt documentation page. This tutorial will illustrate the things you will need to know in order to successfully complete this lab. We're not going to ask you to turn in the code for this part of the lab, but if you don't know Qt well, then you should take the time to work through the tutorial. When you write the code for this tutorial (or copy it from the web site), either use our Makefile or the qmake program, documented on the Trolltech web site.
  2. Now that you know how to write Qt programs, we'll start on the code that you will finally hand in for this lab. Write a simple Qt program that displays a button with the word "Quit" on it. When this button is clicked, the program should exit.
  3. Check out our example code by running
    ~cse332/public/lab4/example
    Click the bottom panel, and enter some text. Hit the Enter key. Watch what happens. Try typing some html formatted text, such as
    This is bold and this is in italics
    Notice that you can edit text in the bottom panel. The first part of this lab will get you to write an interface that looks like, and behaves like, this one.
  4. Implement a class for text display area. This class should inherit from the Qt QTextEdit class. Make sure that is a read-only widget.
  5. Implement a class for the input area. Again, this should inherit from the Qt QTextEdit class but, this time, it should be writable.
  6. Add these new widgets to your program, so that your application looks like ours when it runs. You might find QVBox useful for laying out the widgets. Make sure that your "quot" button causes the program to quit as expected.
  7. Add functionality to your code that will cause it to behave like our example. When you enter some text and hit Enter, the entry window is cleared, and the text appears in the display window.
  8. Modify your code so that it generates a text message from the entered text, and passes this to the display widget. Use your username as the sender in this message, and timestamp it with the current time. This functionality should work regardless of who is running your code (ie, don't hard-code your username in the program).
  9. Modify your display class so that it is capable of displaying all three types of message you wrote for the previous lab. You should display text messages in a format similar to that in the previous lab. The other two messages should be displayed as short information messages. For example:
    [14:32:43] Hello from wds
  10. Implement a logging service that will log all of the messages displayed in the GUI. The messages should be logged to a file named "logfile", and should be stored using the stream output functions from the previous lab. When the GUI starts up, any existing log file should be erased, and a fresh one started.
  11. Implement a button in the interface that turns logging on and off.
  12. Extra credit: Make your application resizeable. If the user manually resizes the window, the individual components should behave in some reasonable way.
  13. Extra credit: Make the display window pretty by adding (appropriate) colors to it. We'll leave the choices up to you, but you should justify your design decisions in your README file.
  14. Extra credit: Make the color choices configurable, either through a Qt dialog, or through a configuration file, or (even better) both. Implement whatever features you need to in the interface. Try to keep the interface simple, and justify any design choices you make in your README file.

Grading

Most of the points in this lab will be for having the code work as described above. We will deduct points for the following things:
  1. Not compiling. If your code does not compile, then you will get no points for this lab. We've been lenient on this in the past, but we will enforce the rule strictly from now on.
  2. Warnings or errors in the compile. Your code should not generate any warning messages when compiled with the -Wall flag.
  3. Deviations from the coding guidelines.
  4. Incorrect or poorly-written algorithms.

What to Hand In

You should use the tar command to package up the files you want to submit. Please do not include executables, object files, or the output from doxygen in your submission file. Do include all of your source code, Makefiles, README files, and testing files. We should be able to rebuild your program from the files you send us.

Once you have everything packaged up, submit your lab using the new submissions page.

Thoughts

  1. This lab will most likely take longer than the last one, since you're learning a new library and toolkit. Please, please, please start early. Of those people who submitted lab 2 before the deadline, only two did it an hour or more before the deadline. This doesn't leave much room for error.
  2. Make sure you work through the first part of the Qt tutorial before you start to work on the main part of this lab. Really, we mean it. If you don't, and you've never used Qt before, you will be at a severe disadvantage when you start writing your own code.
  3. qmake is a make variant that makes it easier to build large Qt programs. You can use it for this lab if you like.
  4. If you're working from somewhere other than the CEC linux lab, make sure you've got the same version of Qt installed. As usual, we will consider the version in the lab to be the canonical version for testing purposes. If you use a different version and we cannot compile your code (which might happen with different major version numbers), you'll get zero points (the penalty for non-compiling code). You can find the Qt version on the CEC linux machines by running
    rpm -q qt-devel
    This will return something like qt-devel-x-y-z-... The version number is x.y.z.
  5. Yes, the code for the first part of this assignment is very close to one of the example programs in the tutorial. See, we told you that you should do the tutorial first.
  6. The initial display and input classes won't have much in them when you first implement them. Don't worry. We'll add more stuff to them as we go.
  7. You should use the signals and slots mechanisms of Qt to implement the communication between the entry and display windows. This means that you will have to put the Q_OBJECT macro in your class definitions, run the meta-object compiler, moc, over it, and compile (and link) the resulting generated code. You will have to implement signals and slots for your new classes, and wire them up correctly (using the connect function) to get things to work correctly. If you haven't done the Qt tutorial yet, now would be an excellent time to work your way through it.
  8. "in some reasonable way" cannot be interpreted as "obeys the default behavior"
  9. Your display class should implement the logging functionality, and should probably implement a slot to allow logging to be turned on and off.
Page written by Bill Smart.