Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
M4 and M5
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:
- A timer widget (used for tracking presentation progression based on a given time and number of pages)
- A text widget that automatically adjusts the size of text based on whitespace
- A link-to-a-page widget that allows linking to an arbitrary point in the presentation, regardless of modifications to said presentation
- An image widget that allows for automatic scaling and rotation of a selected image
- A user interface to select from several layout styles for each page including:
- A Title Slide
- A Bulleted List
- Two Columns of Text
- Title Only
- Text and Picture
- Picture and Text
- Text and Two Pictures
- Two Pictures and Text
- One Big Picture
- 4 Pictures
- A user interface to change the style of the entire presentation, including:
- Background image
- Font color and style
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:
For M5, we added:
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:
- Slides containes all classes that pertain to the slides themselves, including:
- SPMainPasty - The main panel of the slide
- SPPastelette - Four panels that can be shown in any combination, based on constants found in the SqueakPoint-Models category.
- SPPicture - The image component housed inside each Pastelette
- SPTextMorph - The textual component housed inside each Pastelette
- SPTitleContainer - The containing frame for the TitleBar, with much the same responsibilities of a Pastelette (a special case of one)
- SPTitleMorph - The textual component of the Title Bar
- UI Contains all classes pertaining to UI, including:
- SPMenuBar - The Bar that houses all action buttons, and serves as messenger between button action and SqueakPoint proper.
- SPToolButton - A generalized, pluggable button instance that takes user input and relays the prescribed message. It also has pluggable tooltips and graphics.
- Utils includes:
- SPTimerWidget - this probably could have gone somewhere else. It displays and updates based on information it polls from SqueakPoint's accessors.
- SPCore includes:
- SPSqueakPoint - the main class we were to extend. It mostly relays messages between user input and the relevant classes it is composed of.
- Models include two singleton classes that provide a set of extensible formatting constants. They are:
- SPLayoutFarm - a list of constants, composed of more abstract constants within the class, to tell SqueakPoint how to display the current slide.
- SPStyleFarm - a list of constants, composed of font formatting and image references, to change the background and font style of the entire presntation
Now that I've described all the classes up to M4, here's the UML for it:
This category was added for M5:
- Server Contains all classes pertaining to the Server, including:
- SPColorVampire - provides a neat color fade effect when the wrong kinds of morphs are dropped into the DarkPortal.
- SPDarkPortal - provides a nice interface to drop in a presentation, name it, and turn it on or off.
- SPhttpProcessor - Processes the html request and informs the MagicPotato what kind of request is needed.
- SPImageFarm - serves images, chaching them in Squeak upon the first load.
- SPMagicPotato - Takes simple URL's passed to it from the SPhttpProcessor and decides what sorts of HTML to answer back with.
- SPPresentationMorph - These are what the SPSqueakPoint presentations turn into after they've been dropped into the DarkPortal.
- SPServerLauncher - Launches the server, sets a port, and assigns it an HTTP processor.
- SPServerMorph - The launchable class for the entire project. Just open it from the new morph menu.
- SPServerPage - The Morphic-based pages of the SPSqueakPoint class weren't all that great to convert to HTML. These are easily parseable representation of the morphic presentation pages.
- SPServerPresentation - This class contains SPSeverPages and a few other details pertainent to cataloguing and serving the presentations.
Here is the updated UML for M5 (basic accessors and setters are excluded):
Our design philosophy was based on two very simple principles:
- Organic program design and mutation
- Planning for only a general program flow of messages and relating responsibilities to general areas allowed for open and dynamic design and implementation.
- Designing with the aim to avoid implementation specificity allowed our ideas to be realized by adhereing to principles of good design, rather than mere code hackery.
- Simple interfaces for integration
- Thinking initially in terms of categories which corresponded to a problem domain in the project allowed us to think more generally and to understand the mechanics of the program before we began implementing it.
- The separation of responsibilites into categories allowed for us to concentrate on what messages must be passed and/or shared across categorical boundaries, such that the interfaces to all the subsystems were clearly defined before the specific implementation existed.
- Once the interfaces had been established, the expectation of those interface drove the development of categories that had to directly deal with it. This stage brought the existence of other potential classes to our attention, so that as few classes as possible had direct access to the interface and other classes were spun off as their responsibilities and our implementation became more concrete.
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.
- Scalable windows - the windows in the presentation scale automatically based on the size of the presentation, with pixel granularity.
- Scalable Fonts - the font resizing exceeded spec, as it could change size between five font sizes.
- Constants Classes - The constants classes SPLayoutFarm and SPSytleFarm allow for easy modification to the basic proportions of the presentation. For example: the present implementation, based on the specifications, was to have a title bar at the top, and one to four panels underneath. The proportions of the panels were either:
- The full extent of the panel
- The left or right half of the panel
- A full left half and two quarters on the right or a full right half and two quarters on the left
- Four quarters, all proportional
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:
- A user changes from one panel of text to four pictures
- SqeuakPoint tells the current page to change its layout with a constant corresponding to the users choice.
- The current page gives SPMainPasty the notification to change
- SPMainPasty delegates parsing of the change to the SPPastelette(s)
- Each SPPastelette takes its part of the constant, and determines the following from it:
- where it should be
- what its proportion should be
- is an image or text to be displayed in me?
- When each SPPastelette has determined what should be displayed, it tells its submorphs (a picture and a text morph) which to hide and which to show.
- M2 - M4 GUI
We tried to keep the functionality and bookkeeping as seperate as possible from the GUI, but due to the heavily morphic-based nature of BookMorph, this was very difficult at times. For example, the current page number was not stored anywhere in the BookMorph class. Rather, an instance variable called "currentpage" was used to indicate which PasteUpMorph was the current page. SPSqueakPoint needed to receive a large variety of message types to carry out all its responsibilities. It would have been difficult to get each button to be customized to each task without making serveral classes that extended a basic button class. This is where the SPMenuBar came into play. Even though the menu bar was a basic alignment morph to hold the buttons, it also accepted notifications that a particular button was pressed and figured out how to intepret it. Sometimes it simply relayed a message to the main SPSqueakPoint class to go to the next page. Other buttons invoked floating menus that offered more choices, such as the template chooser or the navigation menu.
- M5 Squeak GUI
The Squeak side of the GUI basically consisted of two core classes. The SPServerMorph is the main "container" that initialized the server upon creation. It contained a SPMagicPotato class and a SPDarkPortal class. The SPDarkPortal was a dark rounded rectangle that received Morphs dropped in to it. Upon receiving the morph, it would convert it into a SPServerPresentation for easy parsing and send it to the SPMagicPotato which would deal with HTTP requests. The Dark Portal also had submorphs that extended Iconic Buttons. These buttons, which were linked to SPServerPresentations would disable and enable SPServerPresentations from being displayed at the HTML end.
- M5 HTML GUI
The SPMagicPotato served up all the HTML from watered-down HTTP requests that were provided to it from the SPhttpProcessor. These watered down versions simply had the URL as a string and a dictionary of variables in the URL parameter list (the stuff you see after the ? in URLs). The MagicPotato had methods that simply took in a title of a page and returned an HTML heading and closing that would make unifying all the pages simple. These webiste skins came in two varieties: the skin that contained the splash image at the top and navigation links, and another version that was completely watered down for fullscreen presentation mode. The basic method for generating the HTML was the same for all pages...
The HTML presentations used the same images and layout that was used for the original SqueakPoint presentations, making the HTML version almost indistinguishable from the Squeak version.
- Pick a header for the page with the proper title (fully decorated or watered down for a fullscreen presentation)
- Generate the page contents based on the requested URL
- Choose a closing for the HTML
- Concatenate all these together as a long string
- Send this string back to the SPhttpProcessor to answer the HTTP request that set things into motion.
M4 & M5 Presentation Screenshots
Look, a slide!
Timer Widge settings
Preparing to change the slide 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
List of presentations being served
First slide of the presentation
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:
- AIM - This was used ALL THE TIME. If either of us happened to be at work, a quick question or two would usually get the other guy going. It's also great for copying and pasting code snippets back and forth!
- Person-to-person Meeting - We only did this weekly or biweekly, mostly for design issues and pattern exploration. We tried not to have everything nailed down to an exact specification, in order to speed up development and try new ideas. This worked well.
- email - Useful for when you are on differing sleep schedules or in class. Also useful just as daily updates, or when whatever code repository you use has a change.
- Website - One of us provided a web/php frontend to upload our fileouts. This worked very well for us, as we could create folders and upload all our deliverables into one package that could be verified, reviewed and tested by everyone before it was turned in. It also provided a centralized location for all our work, so we could carry around sqeuak on our USB drives and get to work with the newest code whenever we had an Internet connection available.
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 - M5.zip
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu