View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team T34M

M4 and M5

Blake O'Hare
Steven French
Team T34M


We were required to implement a Power-Point-like presentation program, entirely within Squeak. Although primitive when compared to Powerpoint, Squeakpoint is designed to provide a usable presentation system inside of Squeak, based off of the BookMorph class. The core elements of all presentations for this semester include:

Whats in SPSqueakPoint (our extension of BookMorph)

BookMorph contains some very obvious methods, as well as some that are tough to figure out by just looking at the code. Inspection of morphs and their state was essential to understanding the behaviour of the class. Since we were going to make some changes to BookMorph, we decided it best to subclass it, to delineate normal BookMorph behaviour from our SqueakPoint behaviour. Further, we wanted each responsibility that was an extension of BookMorph to be delegated to a new class, in order to better separate responsibilities. Therefore, our extension of BookMorph was minor, and mostly included special accessors and setters for the customized functionality required of us. There were several messages that were added merely to relay messages from the UI to the classes contained in SqueakPoint (for it was largely an Object of composition) to act on those requests. More on this later.



We created five categories for M4, including:
  1. SqueakPoint-Slides
  2. SqueakPoint-UI
  3. SqueakPoint-Utils
  4. SqueakPoint-Core
  5. SqueakPoint-Models
For M5, we added:
  1. SqueakPoint-Server
Each of the above categories had a complimentary -Tests Category that contained all the unit tests for that category.
Splitting up the classes into categories provided an easy way for us to ascertain which classes belonged to what part of the problem domain:

Now that I've described all the classes up to M4, here's the UML for it:

Uploaded Image: M4.png

This category was added for M5:

Here is the updated UML for M5 (basic accessors and setters are excluded):
Uploaded Image: M5Final.jpg


Our design philosophy was based on two very simple principles:


Some of the features that were especially important and/or cool include:
Our implementation provides for a simple modification of the constants file, such that the presentation could countain 6 or 8 or 2n panels, by building upon a set of primitives with self-evident names like bottom left, quarter, middle, etc.

Containers and what they do

The basis for the scaling and partitioning scheme for the slide presentations is a hierarchical message passing scheme. A typical change in the slide aspect is as follows:


M4 & M5 Presentation Screenshots

First Slide

Slide Navigation

Look, a slide!

Timer Widge settings

Preparing to change the slide layout

Changed layout

M5 Squeak-side Screenshots

Brand New SPServer Morph

Create a sample presentation and drag it in

Presentation turns into an icon

Click to name the presentation

Now that presentation is being served

M5 HTML Page Screenshots

Main Page

List of presentations being served

First slide of the presentation

Slide navigator

Full screen mode

Search for the word "grind"


You might not think it important, but they can make all the difference in the world. Sure, they are a small percentage of your grade, but we all know how difficult it is to organize timeslices for everyone to be there to code together, especially as the due date approaches. Chances are, either you or someone in your group has a project due around the same time as this one, so if you comment early and often, the work stoppages due to WTF moments are rare. This was especially important in our group, as one of us was a nontraditional student with a wife, a kid, a fulltime work schedule, and a fulltime school schedule.


Due to having a TA and a nontraditional student and NO ONE ELSE in our group (our third punked out right before M2), formal methods of collaboration and the whole XP buddy-coding paradigm were pretty much thrown out the window. The following lists our collaboration methods, with the most useful ones listed first:

Fileout passing

Due to the modular nature of both our code and, on a higher level, our classes and categories, most of the time one of us could be working with one set or subset of the categories while the other worked on a different set, without causing conflicts with each other's code. Morever, due to the clean interaces we designed, the major categories only interfaced at a handful of methods, leaving us free to experiment with the internals with little worry of breaking everything.

Our Final Project

T34M -

Other Documentation


Link to this Page