[Assignment 1] [Assignment 2] [Assignment 3]

COMP2100
Assignment 3: Graphical User Interface

Due at 5pm on Friday 28th May 2004

Hints and FAQ

The next stage of the project is a graphical viewer for Open Office XML documents. The team leader has produced a very rough prototype, then suddenly departed (for a highly-paid job at Microsoft), leaving the work incomplete. You have to pick up the pieces and complete the job.

(It may not be quite clear to you why you're writing a graphical interface to oops since it was supposed to be a web-based preflight system. Who knows what management and marketing are thinking? You're a software engineer, and the way things work these days, you just have to do what the people in the suits want.)

You are to carry out the following tasks:

1. Add code to make it format documents a little better.

2. Add a menu bar with a File menu and a View menu.

3. Add a new viewing mode that displays the document's XML structure as a tree widget.

1. Format the document

The code you have been given will display the contents of the document in a window, but it's all in one paragraph with no formatting at all. Your task here is to modify the GUI_RENDERER so that it formats the document a little better. Within the pages, it should look very roughly like what you see in your web browser when it displays the HTML version of the document. Specifically:

1. At the moment it tries to write the document onto "pages" that are displayed one below the other in the viewing window, white against a black background. Change this so that the entire document is shown directly inside the window, like in a web browser. Instead of several pages, it's just one page that is as long as the document.

2. At the moment the line length is determined by the width of those "pages". Change this so that the lines are the width of the window (apart from a small margin at the edges). Also change the behaviour so that the document is reformatted when the window size is changed -- just like a web browser. (This is actually easier than what the prototype is trying to do. It's mostly a matter of removing fancy code we don't need, rather than adding new code. You'll also have to figure out how to have it redraw when the window is resized.)

3. At the moment the whole document is displayed in one paragraph on the screen. Change this so that each paragraph or heading starts on a new line, with a blank line in between.

4. Don't worry about different fonts for different parts of the document (bold, italic, larger, smaller). Just do everything in Times 18 as it is at the moment.

Obviously there's a lot more that you could do to make this display look attractive (or just more like the browser view of the HTML version of the document). In particular, handling a whole lot of different fonts would make things look much nicer. Also varying the margins, the amount of vertical space and so on. That was all in last year's assignment, so I'm not asking you to do it this year. Don't be tempted to waste time on this. Keep it simple -- as described above -- and then move on to Questions 2 and 3.

2. Add menu items

At the moment the program just displays the file named on the command line and then stops. It doesn't recognise any events except the automatic things that happen when the window is resized, moved, iconified or closed.

Add a menu bar to the top of the window, with two menus called "File" and "View". In the File menu, add two menu items, "Open" and "Quit". In the "View" menu add two menu items "As Text" and "As Tree". Then add code to class CONTROLLER so that these items are associated with the following actions:

1. The "Open" item should cause the program to pop up a file selection dialog widget. (Use an object of class EXG_FILE_SELECTION_MODAL for this.) The dialog box should have the title "Open document" and should open looking at the directory that the current document came from. When the file selection dialog returns, if the user clicked "Cancel", then do nothing. If they clicked "OK" and there was a file selected of the correct type, then the program should open this file, parse it and display it. If there was no file selected or if there was a file selected, but it was the wrong type, or it didn't exist or it couldn't be opened for whatever reason, pop up a message box with an error message.

2. As an extra feature, allow users to open two different types of documents. The first is OpenOffice word processing documents with extension ".sxw". The second is XML documents with extension ".xml". The application should open OpenOffice documents in the default text view. For XML documents, however, the application should open the document in tree widget view mode (see Q3 below), and not allow the user to change to text view mode. (See the specifications for the View menu below, and also Q3. It doesn't make sense to work on this part until you have the tree view mode working.)

3. Make it possible to open the application without specifying a document on the command line. In this case, the main window should open but be left blank, and the application should immediately pop up the file selection dialog on top of it for the user to select their first document.

4. The "Quit" item should close the application.

5. The "As Text" item in the "View" menu should be greyed out (made inactive) when the document is displayed in the default text view. When the document is displayed in the tree widget view (see Q3 below), this menu item should be made active. Selecting it should change the application back to the default text view.

6. The "As Tree" item in the "View" menu should be active when the document is displayed in the default text view and inactive when it is displayed in the tree widget view. When clicked it should change the application to display the current document using a tree widget. (See Q3 below.)

3. Add tree widget view mode

Add a new viewing mode to the application that displays the XML structure of the current document using a tree widget. (A tree widget is like the thing used in Windows Explorer or other GUI tools to display your directory structure. When you click on a little plus sign, it opens up and shows the children of a node; when you click on a minus sign it closes that node back up again.) Use class GTK_TREE for this. You'll need to look up the GTK documentation as well as the EXG short forms. The tree widget view should appear in the main window, replacing the default text view.

For each node in the parse tree structure, you will need to create a node in the tree widget. If a node has children, you will need to add a subtree to it containing those children. Each tree node has a string (label) associated with it. For XML elements attach the element name and attributes as the label. (You may find the to_string feature of class ATTRIBUTE_LIST saves you some work.) For data elements, just attach the content. You don't need to do anything about handling the mouse clicks on the little plus and minus signs; once you have built the widget, it handles all that by itself.

Link this code up with the items in the View menu so that the user can change their view of the document by selecting the different menu items.

---

Getting started

Download the compressed archive file a3start.tar.gz. This contains the source code for the starting version of the program. Uncompress and unpack the archive into a fresh directory.

Compile the program by typing make. There are eight sample Open Office word processor documents provided.

Take time to read and understand the code before you try to modify it. Don't just dive in and start changing things until you understand how they work.

Advice

I recommend that you place each class you modify under version control with RCS, so that you can keep track of the changes you make and go back if you mess up something that was working. Modify the header so that it looks like this:

-- $Author: $
-- $Revision: $
-- $Date: $

and make sure that you check it in and out after each significant lot of changes. I usually find it easiest to use Emacs for this: do C-x v v to check in or out, and C-c C-c to tell it that you've finished typing your log message. Take the time to put meaningful log messages, so that you can choose the correct version more easily if you have to go back.

If you don't understand something in the requirements, send your questions to comp2100@iwaki sooner rather than later. I will post some of the answers to the Assignment 3 FAQ and Hints Page, so check there before you write to me. I will also leave some of the relevant questions and answers from last year there.

Question 1 is pretty much independent of the rest of the assignment. Question 2, parts 1 and 4 don't affect anything else either. Question 2, part 3 stands alone. Question 2, parts 5 and 6, and Question 3, all go together. Question 2 part 2 you should probably do last, since it doesn't make any sense without the rest.

There's not very much time for this assignment: three weeks and two weekends. Don't stress too much. Do what you can. If you've got this far, you're doing OK.

---

Submission

Submit your assignment as a compressed tar archive by moving to the working directory and then following these steps:

tar cvf a3.tar Makefile oops.ace *.e */*.e
gzip a3.tar
/dept/dcs/comp2100/bin/submit_a3 a3.tar.gz

Make sure you follow those steps precisely, or some of your files won't get collected in the tar archive. Read carefully through the output of the submit script to make sure that there were no problems with your submission.

Use the markshow command to check exactly what files you have submitted and when.

Marking

Your submission will be marked out of 20 according to a standard marking guide. Your program will be compiled and run on test data as part of the marking process.

Your assignment mark will be based on: the correctness of your submitted program, the clarity, readability and simplicity of added or modified code, documentation of added or modified code using header comments and other comments, and compliance with the Eiffel style guidelines on the Eiffel Coding Standard Page. Make sure that the version you submit will compile and run, even if it won't do everything it is supposed to. You will be penalised heavily if your program crashes or fails to compile.

We will make every effort to return your assignment to you before the final exam.

Late submissions

Late submissions will be accepted up to one week after the deadline. They will be penalised four marks (20%).

[Assignment 1] [Assignment 2] [Assignment 3]