Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Squeaky Wheel Inc.
This was the first milestone in the list of 6, all 6 of which are discussed here, and the
choices we made on how things were implemented, in conjunction with comments, problems,
and concessions we had to make when implementing our design. Take careful note of Mile-
stone 2, the main design stage. Careful planning during the implementation of your
project should hopefully yield the results we had.
Although we all had individual turnins of milestone 1, this is a description the best parts
from each of our turnins.
appear at the specified screen coordinates between the given times. The movie starts at
- addPictureFile:at:fromSeconds:toSeconds:- schedule an image from the specified file to
time 0 seconds. The coordinates 1@1 are at the upper left corner of the screen. Note:
image times may overlap! The picture file will be either a JPG or a GIF.
This method took in a file and placed it in an OrderedCollection where the picture, as
placed in a PicClip which knew when it needed to start to play, and when it needed to
stop playing, in addition it knew where to to play "at", meaning a point on the screen.
(i.e. 5@50). In this case, the picture is playing when it is being shown on the screen,
and is "stopped" when the picture ceases to be seen.
each picture to be displayed, its location, and the start and end time for displaying it.
- printSummary - print a summary of the movie to the Transcript. The summary should include
This method, which turned out to be very similar and actually used in milestone 3, sends
the entire movie information to the transcript. In milestone 3, this method was used to
send the text to a Morph, where the user can view and inspect the movie, and click close
- play - play the movie from beginning to end.
This method, the heart of milestone 1, traverses its way through the orderedCollection
of clips, reading the contents of the clip, the information which tells where to play
the clip and when to play and stop the clip, and does just that. Basically its a whileTrue
block of code and it loops through the clips.
For readers of this entire file, if you are reading this before you complete any other
milestones, doing a little extra homework on how to make the first milestone work flawlessly
may very well help you exponentially later.
Here is the list of requirements for Milestone 2 and we how we implemented them.
one walkthrough of a usage scenario. (You should really have several scenarios that you
- A description of the user interface, including at least one screen mockup and at least
have walked through informally, but you are only required to document one of them.)
For this milestone, each of the 3 members of the group drew in paint or powerpoint 3 of
their views of that the user interface should look like. Based on their experience in
GUI's, what each person does and doesn't care for and overall ease of use, we decided to
go with one where there is a main window which holds the contents of the movie (the movie
frames), and a menu bar where buttons can be added. From this, windows can be obtained by
clicking the edit movie button, adding frames, and modifying the movie contents. We felt
that it was important that movie clips fit in the movie window, and not use the actual
desktop of the user as the base for clips. Because of this, implementation included
formatting the pics relative to a specific set of coordinates. Our GUI design proved to be
more than we had imagined, and quickly during the implementation phase in Milestone 3 of
that GUI changes were made to the appearance, although no actually loss of features
occured. Knowing the abilities of the language, and the time that has to be put into the
GUI to obtain certain results could have headed this off the pass, but in any event the
GUI did aquire complete functionality.
- CRC cards for the program.
This was relatively simple, the actual design of the project lended itself to these cards.
They were very helpful during implementation, being able to lay them out and observe the
'complete' picture. Also having hard copies of the design help when you want to make quick
notes. When you (the next semester student) are designing your project, make sure to take
careful consideration of these cards as they just make the whole process of design more
tangible. We even had a nice plastic baggy that was freezer burn free when we turned them
in so the T.A. wouldn't lose them (hint hint).
one, but you are only required to document one of them.
- At least one scenario, along with a walkthrough. Again, you should really have more than
The scenario we chose to turnin with a walkthrough was the adding of a clip to the movie.
Stepping through more than one of these is a !very! good idea, as it gives the programmer
a very clear view on how easy or hard, ambiguious or obvious doing a certain thing in the
program you are writing will be. Take careful steps to insure you don't assume certain
things about the scenario, even down to the mouse-clicks. If you are having to think about
what you need to do to accomplish a task, it maybe a signal of problems to come during
implementation. Everything should be relatively straight forward, just make sure you dont
have to click the pause button, to add a clip ;)
- A UML diagram of the classes in your system
From the writer of this report, the UML diagram was one, if not the best part of this
milestone. Working with UML software is a great experience, especially the piece we chose,
Rational Rose. Basically you sit down with your partners and layout all the classes,
showing how each interact, and hopefully getting an insight into any obvious problems that
may cause you headaches later. This is a very crucial part to the whole process of the
semester project, failure to lay out things in detail and plan carefully here will "kill"
you in the later milestones. Our design, which was laid out in detail using Rational Rose
and CRC cards proved to be very versitile in the last 2 "secret" milestones. If you are
working in Rational Rose and you end up with 1 class doing everything, rethink the whole
process as it's very possible you will be hurting later. Our main layout had a main Movie
Class, a MovieUI, a Scheduler, and Clips. The Clips class which lead to a very easy
milestone 5 and 6 was very important. We were able to create Button clips, able to stop,
start, play, and pause the movie; in addition we were able to add the midi's, wav's
pictures and mpeg clips very relative ease.
- A division of the assignment into tasks, including which team member will do which tasks.
Although this may seem trivial, the careful consideration of division of tasks will lead
to easier times later in the milestones. Make sure to distribute tasks as evenly as
possible, and if someone (will happen, guarenteed) is given multiple items to fullfill,
try to give that person items that are closely related. Even though in a good design,
classes really dont need to understand how each works, the programmer does. If someone is
working on the GUI, then you send them on something in the back-end of the project, they
may have to relearn all the stuff that the previous member had done, and that is a very
misallocation of time. Thoughtful delegation of responsibility can exponential decrease
the amount of time that everyone has to expend on the project, and may even make the
project work better and more functional. As for our project, Clips were given to Jim, the
Scheduler to Brett and the GUI to Chris. After each was completed, they were almost
flawlessly integrated, and testing went great!.
- A timeline for finishing each part of the project
This was the last item on Milestone 2's list of requirements. After we had divided the tasks,
we carefuly analyzed the different classes that had to be completed by the next milestone,
along with the responsibility of each member, in conjunction with the resources we had on
the language that was being used for implementation. We made rough estimates on how much time
each class would take, allowed for that time along with a little "leway", and made sure to
account for testing and integration time. If we had hindsight, we probably would have given
a little bit more time to a couple of the items on the timeline as the integration and testing
took 4 days less that we had planned. Although that is much better than it taking 1 day more
than we had planned. If you plan ahead and don't wait until the last minute, delegation of
tasks and timeline for each part of the project will be very easily completed as desired.
Here is a list of this milestone's requirements and how we implemented them.
- View the current contents of the movie, including the list of
image files and the times that each image will appear.
Each subclass of Clip inherits a method called #summary which it is expected
to overwrite. The #summary method returns a String that gives information
about the clip. Thus, a loop can be run on the clipList to build one String
creating the overall summary for the movie. The clipList is sorted by start
times, making the summary also in order by start times. After clicking the
Summary button on the main UI window, a new System Window pops up containing
the summary string and a "Done" button that closes the window. This
implementation worked well with later media types because the only thing
that we had to do was to overwrite the #summary method in subsequent
subclasses of Clip, never again changing the functionality of the overall
- Add a new picture to the movie.
As described in Milestone 2, our design included an abstract like Clip class
that would have its functionality in its subclasses like PICClip, MPEGClip,
WAVClip, etc. We created a method in the Movie class that would add a
PICClip to the clipList taking in parameters like the filename, start time,
end time, and location of the picture. Now we just needed the user to be
able to graphically enter this information rather than using workspace
commands. We created the UI to have all of its functionality buttons along
the left-hand side, with the remaining area as the movie display section.
The first button that we added functionality to was the add clip button.
When the user clicks the add clip button, he/she is prompted (using
FillInTheBlankMorphs) for the filename of the Clip, followed by the
remaing necessary information. This data is then passed along to the movie
class, which, as explained above, adds the new clip to the clip list.
- Remove a picture from the movie.
This was a little bit tricky, but we finally worked it out so that if the
user clicked on the remove clip window, another window containg the
filenames for each clip would be displayed. By clicking on the name of the
Clip, we could just use the #remove: method (since the clipList is an
OrderedCollection) to easily and entirely remove the clip from the movie.
- Modify the start time, end time, and location of an image.
We used a similar mechanism to the remove picture code to get the clip
which the user wanted to modify, only instead of deleting the clip, we
prompted the user (using the FillInTheBlankMorphs from the add clip code)
to enter new data about the clip.
- Play, pause, resume, and rewind the movie.
This is where the scheduler comes in. The scheduler would respond to the
the UI's play button by setting the current time to zero seconds and then
proceeding to create a thread of prioity level 3 (we played around with this
number and found it to be the best for our needs). While the scheduler is
running, it checks the clipList for clips which need to play or stop, based
off of their stop and start times.
Pausing at this stage was fairly simple. Just stop (or start, if unpausing)
the scheduler's thread at the current time. When the UI's pause button is
hit, it toggles the scheduler between paused and running. The design of
the scheduler took care of the rest.
Rewinding the movie was also pretty simple. When the user hits the rewind
button, the display screen is cleared and the scheduler's current time is
reset to zero.
Using our design of the abstract Clip class with MPEGClip, TextClip, MIDIClip,
and WAVClip as subclasses of Clip meant that most of the work for adding,
removing, modifying, pausing, playing, and rewinding had alreadly been done in
Here is a list of this milestone's requirements and how we implemented them.
- MPEG movies. Display the video frames from an MPEG movie file.
This is one step where we ran into some major problems. Our original design
and implementation had been using Squeak 2.8, but we couldn't get the MPEG
codec stuff working at all. We asked around, only to find out that most
everyone else said that using Squeak 3.0 or 3.1 made the MPEG playing much
simpler. After learning this, we tried to open our project in Squeak 3.0,
only to find that the AlignmentMorphs that we had used for our UI layouts
were no longer used in Squeak. We struggled with it for a few hours and had
to remove some of our fancier GUI stuff, but we were able to finally rewrite
several sections of code to make our project work in Squeak 3.0. Now MPEG
playing was much easier and minimal code was required to implement the playing
of an MPEG.
- MIDI files. Play the sequence of notes stored in a MIDI file.
- WAV files, for sound effects. Play the samples stored in a WAV file.
Both of these requirements were failry simple to implement because of Squeak's
built in multimedia capabilities.
- text messages. Display a string of text at some location on the screen,
for a specified amount of time.
This requirement was also not very difficult as we simply took the given text
file and made it the text on a PluggableTextMorph with the boundary width set
to zero and the scrollbar hidden.
- It should be possible to save movies to disk and then load them in another image
on another computer. The movie should be saved in a single file. The user
interface should be updated to allow saving and loading movies to disk.
This part took a little thought and we had to experiment with a few things
before we could get it to work. It wouldn't have been as hard except for the
requirement that we had to take all of the necessary files (MPEG's, WAV's,
JPEG's, etc) and put them into one file. Our first thought was to basically
copy all of the necessary files byte by byte into one larger file. We never
could get this to quite work right, so we stumbled upon another approach.
We remembered that Squeak allows you to file out Objects, so we could just file
out the Movie's clipList variable, along with a little bit of other information
regarding the formatting of the movie, and we were almost home free! This
method worked well because each Clip held its own media, rather than each Clip
trying to directly access its respective media files when playing the movie.
The code was almost as simple as opening a FileStream, calling #nextPutAll: with
the clipList as a parameter, and then closing the file.
Reading back from the written file (once we had figured out how to correctly
file out the movie) was as simple as clearing the current clipList variable and
replacing it with the one we were filing in.
- Additionally, for at least one operating system, work out a mechanism for
conveniently loading and playing movies the way a normal movie file would be
played back on the operating system. For example, on Macintoshes or MS Windows,
perhaps find a way that double clicking on a movie file and play it back. On MS
Windows or Unix, perhaps write a "playmovie" batch file or script that takes
one argument and plays it would be acceptible. It is okay if you need a special
Squeak image file, so long as the same image file can be used to load any movie
For our first platform, we chose MS Windows 2000 (mostly because that's the
main environment under which we had been working). We followed the directions
about how to create a batch file and it worked quite well! It even turned out
that we didn't need a special image file to do this.
As of this time, we have yet to receive our milestone 6 grade, but we thought that
we might as well finish up the Squeaky Wheel, Inc saga for the sake of finality.
Here is a list of this milestone's requirements and how we implemented them.
- Now it should be possible to add components that can modify the way the movie
is played back. The following components should be accessible to users:
This fit perfectly with our abstract Clip class. With the similar functionality
of each of the three types of buttons, we subclassed Clip to make another
"abstract" class called ButtonClip. Each ButtonClip holds a
PluggableButtonMorph that the user can click. We then subclassed ButtonClip for
CodeButtonClip, PauseButtonClip, and SkipButtonClip. As with adding the later
media types, the playing, pausing, rewinding, and summaries of these clips were
almost entirely handled by the alreadly existing code from milestone 3.
- The following components should be accessible to users:
- buttons that pause and resume the playback (one button that does both).
This button's functionality was easy to implement because all we had to
do was call the pause (which also functions as the unpause) method in the
movie class every time the button was clicked.
- buttons that skip to a certain position in the movie, specified as a time.
This button was also fairly simple, as every time it was clicked the
scheduler's current time would be set to the time the user had inputed
when the button was created.
- buttons that allow advanced users to insert code. The code should be able
to access the movie object, and ask it to do things like pause or jump to
a specific frame.
This button was the most difficult, and we finally settled for the button
clicking to just pause the movie and open up an inspect window on the Movie
object so that the advanced user could modify it as he/she pleased.
- Work out playing back a movie on a second OS, just as was done in Milestone 4.
Again, submit instructions and a sample movie.
For our second OS, we chose the Linux Red Hat 6.2 machines in the states
cluster. All we had to do was to write a simple script similar to the batch
file from milestone 5.
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu