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

COMP2100
Assignment 3: Graphical User Interface

Due at 12 noon on Friday 6th June 2003

(Extension to 9am Wednesday 11th June available if you want it. No need to apply.)

Hints and FAQ

The next stage of the project is a graphical viewer for Open Office documents that incorporates the style and metadata features from Assignment 2. The team leader has produced a rough prototype, then suddenly departed (for a highly-paid job at Microsoft), leaving the work incomplete. You have been selected to take over 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, but 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 they want. One day, when we engineers take over...)

You are to carry out the following tasks:

1. Add code to make it format documents appropriately (rather than just displaying all the text unformatted as it does now).

2. Add a menu bar with a File menu containing items to open a new document, display metadata and quit the application.

There are a few tasks marked as Optional below. They are not really part of the assignment. Ignore them until you have finished everything else. If you have more time and are interested, then you might want to have a go at one or more of them. Tutors may award up to two bonus marks for good work done on these tasks, but will only look at them if everything else is working properly.

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 correctly. Within the pages, it should look roughly like what you see in your web browser when it displays the HTML version of the document. Specifically (in no particular order):

• Display documents with more than one page correctly. At the moment you only see the last page, with some lines at the top of the screen. This needs fixing.

• Use Times 12pt for ordinary text. (At the moment it's using 18pt.)

• Use bold and italic fonts where appropriate for "span" elements. (See the existing text and HTML renderers for how to identify bold and italic spans.)

• Start each paragraph on a new line. Paragraphs with style "Initial Body Text" should start at the left margin like ordinary lines, but paragraphs with style "Text body" should have the first line indented by two ems. (An "em" is the width of a capital "M" in the current font.)

• Display headings in large bold fonts (24pt Times bold for the article's title, 18pt Times bold for Primary Headings, 12pt Times bold for the Author's name and Secondary Headings.

• Add a few pixels of extra vertical space before all headings. Use your discretion, but make sure it's enough that your tutor will notice it - but not so much that it's silly. Roughly one blank line might be a good amount to start with.

• Display the title, author's name, affiliation, displayed equations, figure captions and table heads centered on the page. (That is, with the same amount of space on the left and the right.)

• Display the abstract, categories, footnotes and figure captions in a smaller font: Times 10pt.

• Display the abstract and quoted text between narrower margins. Make it a bit more than the first line of paragraph indentation: say 4 ems.

• Show displayed equations in Times 12pt italic.

• Implement entity replacement much as you did for the text renderer in Question 1 of Assignment 2. This should be easy for "&", "<", ">", "'" and """. As for the copyright symbol, it seems to display OK, but you'll need to get rid of the "Â" that gets put before it.

There's a lot of things to do here. Do as many as you can in the time available, but don't worry too much if you don't get all of them. It's certainly not "all or nothing".

To do the part of this concerned with different fonts, you will need to modify the code for creating fonts so that your GUI renderer creates each font it needs, but creates it only once. The code that is there now was written without thinking about this. If you create fonts and throw them away, there will be a memory leak on the C side of the application. You must avoid this. I suggest making each font a once function that calls a new_font routine with appropriate parameters for size, slant and weight. Then you might want a variable current_font that points to whichever of the fonts is currently selected. You'll need to fix something similar for the font height information since it varies between fonts.

Optional: The way the background is drawn is wrong. Get rid of the ugly black border around each page. Instead, make it display each white page against the default grey background. Also change the default window size so that the full width of the first page can be seen, with the same amount of the grey border showing at the top, right and left.

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 one menu called "File". In that menu, add three menu items, "Open", "Properties" and "Quit". Then add code to class CONTROLLER so that these items are associated with the following actions:

• The "Open" item should cause the program to pop up a file selection dialog widget. (Use 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.

  Optional Make it possible to open the application without specifying a document on the command line. One way to do this is to open the main window but just leave it all grey until the user opens a document via the menu. Another option is to pop up the file selection immediately and only show the main window once the user has selected a document. Choose one of these options and implement it.

• The "Properties" item should open a popup window that displays the document metadata: Title, Author's Name and Affiliation. Exactly how you display this is up to you. What is important is that the information should be there and should be clear and readable.

• The "Quit" item should close the application.

• Optional: Add another menu item "Export". Make the "Export" item open a sub-menu with two items "as plain text" and "as HTML". The two subitems of the "Export" item should cause the program to open a file selection dialog so that the user can choose the name and location of the exported document. The title of the dialog box should be set to "Export document as text" or "Export document as HTML" (depending on which subitem was selected). The default file should be the same as the filename of the current document but with ".txt" or ".html" in place of ".sxw". As above for the file open dialog, do nothing if the user clicks "Cancel" or doesn't select a file. If they do give a file name, check if the file exists. If it does, pop up a dialog box saying that it already exists and asking them if they want to overwrite it. If they agree (or if the file didn't already exist), use the appropriate renderer (TEXT_RENDERER or HTML_RENDERER) to write the reformatted version of the document to that file name.

---

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 five 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.

Do not start any of the optional sections until you have completed everything else to the best of your ability. Tutors will only look at work on the optional sections if everything else is working.

There's not very much time for this assignment: just over two weeks to the official deadline; three weeks until the unofficial extended deadline. Don't stress too much. Do what you can. Make some effort towards both parts. The "Properties" popup should be easy. So should some of the formatting tasks. Opening new documents has some surprises. Getting the fonts working right without memory leaks isn't too hard if you follow the hint.

---

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 comp2100 a3

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]