Index by Week ↓ [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]

This is a 10-week computer science course about elementary GUI programming at the college sophomore level, supported by lectures at Cal Poly Pomona.

Course grade is based upon

♦ the (4 to 6) projects, including oral interview about your design and implementation (80% of grade)
-- Projects should be worked on and completed in a timely fashion over the 10 weeks of the course.
-- Students should attend (nearly) every class session and engage instructor and other students about projects.
-- Demonstrate partial solutions in the lab sessions and seek feedback from instructor and other students.
♦ short exams or "quizzes" regarding GUI programming design and implementation (20% of grade)

The Java Tutorials at http://java.sun.com/docs/books/tutorial/ are useful. Those tutorials provide a wide variety of examples showing the use of Swing components in GUIs.

Week 1 -- Basic GUI Principles, Design and Construction

This article gives basic definitions for terms associated with grahical user interfaces, some historical background, and many examples of various notable GUI implementations.

This article, and its major links, provide basic definitions and examples for many useful GUI widgets, such as buttons, sliders, menus, layouts, text components, etc.

♦ Download and try JavaEditor (↵ right-click and save to Desktop). The instructor will use JavaEditor to demonstrate Gui program development in the lectures. The JavaEditor is a mini-IDE and is also an example of a portable Java application. A portable Java application is, roughly speaking, an application which runs reasonably on every platform supporting Java, and which is delivered as a jar (Java archive) file.

♦ Demonstration mini Project. The goal is to construct a simple little calculator whose functionality and apprearance resembles the one in the snapshot below (on left, from Mac desktop). The intention is to construct a portable version that runs on all platforms supporting Java, including a version that can be embedded as an applet in a webpage. The diagram in the middle image below depicts the file arrangement for the various versions of the calculator on this server. The various versions add features to the basic design in an incremental fashion. The rightmost image below depicts a component "blob diagram" for the various components specified in the calculator, Version 1.

Version 1: Calculator.java Basic code for our calculator layout and a window in which to run. No functionality in this version. The GUI uses a javax.swing.JFrame having a java.awt.BorderLayout to hold a javax.swing.JTextField (the calculator display) and a javax.swing.JPanel (the calculator keypad), and the panel has javax.swing.JButton keys arranged in the panel using a java.awt.GridLayout .

Version 2: Calculator.java Modify for system "look-and-feel", use Unicode symbols for sign change and divide, align display text to right, and experiment with keypad font size. Still no functionality.

Version 3: Calculator.java Add some functionality, some "action". The Calculator implements the ActionListener interface, which requires it to define the actionPerformed(ActionEvent) method. Prior versions supplied an empty body for the actionPerformed method. The v.3 prototype indicates how to add the calculator itself as its own ActionListener for to the buttons and modify the actionPerformed method to trap the button ActionEvents. Not all simple calculators work the same way: The Mac desktop calculator uses a calculation LIFO stack, e.g., 3+3x5=18 but my little plastic Texas Instruments calculator gives 3+3*5 =30, probably because a simple accumulator is cheaper than an electronic device which can implement a stack.

Project 1: Decide on a particular computation method and implement your method for your Calculator. Use the GUI to test your implementation decisions. This is a good elementary example of a project in which an implementation of a GUI -- even if not finished -- can provide a useful testbed for implementing the underlying program logic. One intends to validate the logic of the Calculator control by using the GUI to supply inputs and observe outputs (and do the math with paper and pencil ;-) !

Version 4: Using the Calculator JPanel, create CalculatorApplet.java which is embedded in this webpage using the following markup code:

<center>
<APPLET 
   codebase = "./"
   code = "CalculatorApplet.class"
   width = "275"
   height = "300"
>
<param name = "fontsize" value = "12">
</APPLET>
</center>

which appears like this:

Notice that the not-fully-functional prototype is embedded here, from Version 3, where only keys C, 0 and 1 respond to clicking.

Version 5: Archiving the Calculator. Copy calculator/4 to calculator/5. From within ./calculator/5, the following command created Calculator.jar :

      jar cvfm Calculator.jar MANIFEST.MF Calculator.class CalculatorApplet.class

The manifest indicates the main class to run if the jar is launched by double-clicking on its file icon or running from the command line like this:

      java -jar Calculator.jar

Calculator.jar is an example of a portable jar: In this particular case it can be downloaded and run as a desktop application from the jar or the jar can be used to supply executable code for an applet.

In order to use the archive as the code source for the applet we should use this html splice (archive rather than codebase):

<center>
<APPLET 
   archive = "./calculator/5/Calculator.jar"
   code = "CalculatorApplet.class"
   width = "275"
   height = "300"
>
<param name = "fontsize" value = "12">
</APPLET>
</center>

Week 2 -- More GUI components and MVC Design Patterns

This article describes the MVC -- Model View Controller -- software patterns for GUIs. The "model" encapsulates the data associated with the GUI, the "view" is a visual representation of the model(data) in the GUI, and the controller enables GUI-mediated changes in the model(data) that are consistent with the view of the model(data). Each of the calculator swing components has its own separate MVC description, and so does the calculator itself: The Calculator model involves the numerical data for computation (which we saw could vary, depending on the kind of calculator), the view is the visible GUI, and the controller involves the ActionEvent handling mechanism.

This article describes the the topic of human-computer interaction, and has a discussion of design principles, design methodologies, and THIRTEEN PRINCIPLES OF DISPLAY DESIGN.

      toolbar = new JToolBar() ;   // can hide from Options menu
      toolbar.setBackground(shadeColor) ; 
      Class cls = this.getClass() ; // for reference to resources in jar

      JavaEditor_icon = new ImageIcon(cls.getResource("images/JavaEditor.gif")) ;
      JLabel dropLabel = 
         new JLabel(JavaEditor_icon) ; 
      dropLabel.createToolTip() ;
      dropLabel.setToolTipText("FILE DROP SPOT") ; 
      dropLabel.setTransferHandler(new DropFileHandler()) ; 
      toolbar.add(dropLabel) ; 
      toolbar.add(new JToolBar.Separator()) ;       

      ImageIcon new_icon = new ImageIcon(cls.getResource("images/new.gif")) ; 
      JButton newButton = new JButton(new_icon) ; 
      newButton.createToolTip() ; 
      newButton.setToolTipText("create new document") ; 
      newButton.setBackground(shadeColor) ; 
      newButton.addActionListener(fileActivator) ; // same as "new" on menubar
      newButton.setActionCommand("new") ; 
      toolbar.add(newButton) ; 
      ... 
      Container c = this.getContentPane() ; 
      c.setLayout(new BorderLayout()) ; 
      c.add("North", toolbar) ; // at top, under menu 
      ...

♦ Project 2: PushButton Design the "View" for a "push button" that meets the following requirements:

the button has an explicit "state" -- on/true or off/false
the button appears raised up when "off"
the button appears sunken down when "on"
the button text is centered but "shifts" for perspective when switched on/off
the preferred size of the button is the size required for the text and a margin all around
Define (override) getPreferredSize() to reflect this size requirement
the text color on the button is set using setForeground(Color)
the background color on the button is set using setBackground(Color)
the text font is set using setFont(Font)

The following diagram depicts the simple (Cartesian) geometry values for the button:

The dimension (tw,th) is the value return by getTextBounds(-).

Assume that the margin around the text is m, for all four margins. Then the preferred size is

(tw + 2*m + 3) by (th +2*m + 3)

x ~ (w-tw-3)/2 - 2
y ~ (h-th-3)/2 - 2

x ~ (w-tw-3)/2 + 2
y ~ (h-th-3)/2 + 2

These calculations are suggestive (do it this way and it will be ok), not proscriptive (doing it another, similar, way might look better).

⇑

Week 3 -- More Design concepts ...

♦ Demonstrate your solution for Project #2 (PushButton) by Friday of next week, January 30.

♦ Lecture on Wednesday regarding design for PushButton. See the class diagram posted above (last week).

⇑

Week 4 -- A Simplified Incremental Design Process

For example, the Calculator project was introduced in just this manner: several versions were presented. The first version creates the GUI without much functionality. This first version gives a "VIEW" (a "peek" really) without much functional content There is probably no real "CONTROL", although some Listeners may be defined, and perhaps little detailed "MODEL", although some data structures may be defined.

Subsequent versions add "CONTROL" and "MODEL", and modify the "VIEW" accordingly, as necessary. In the following diagram, think of the triangle whose edges are labelled 0, as the first prototype, or Version 0. The intention is to make this version of the code be executable, even if it cannot really do anything useful yet. The subsequent versions all describe some additional aspect of the overall requirements in such a way that the functionality for that aspect can be added to the evolving prototype, can also be made executable and thereby testable. Typically the code for version N+1 starts with a copy of the code for version N.

The primary drawback to this process (as a completely formal process) is that it would be difficult to go back several version to make a substantial change, because there is no way to formally propagate the change to the later versions. Instead the change needs to be made in the current version.

Many programmers use a style quite similar to this, but many do not save all versions explicitly. An even less formal approach could use the incremental steps but only archive one last confident version, and reversion to this last version is possible in case the next increment fails to work and needs rethinking.

Incremental Design Diagram

The next project will be started using this incremental design process.

♦ Project #3: Create a drawing application that can draw freehand (scribble) and straight lines with the mouse (CONTROL). The scribble drawing uses mouse dragging. Straight lines might be drawn using the shift key with mouse down to start, mouse drag, mouse up to end. The straight line "rubber bands" until the mouse up occurs. Or, there could somehow be two drawing modes (scribble or straight line), and mouse dragging either scribbles or rubber bands straing lines, depending upon mode, until the mouse is released. The elements in the drawing are real data, part of the MODEL, and the VIEW of what has been drawn should persist.

Enhancements:

1. The last element (scribble or straight line) can be undone.
2. User can save drawing to file, or open previous drawing.
3. User can select pen color and width.
4. Exit asks user first (before closing) if any drawing occurred.

Version 0 Draw.java: A possible initial arrangement of components, but no interaction.

Version 1 Draw.java: ver.0 + a little action: rubber band straight lines, using mouse dragging while shift down. Shift down is not a requirement, but it is a possible design decision. Describe other scenarios where scribble or straight-line modes can be distinguished. No persistence of data yet, just demonstration of the rubber banding "trick".

⇑

Week 5 -- More Incremental Design for Draw Project

Version 1a: A little experiment for scribbling. Draw.java: ver.1 + simple drag for scribbles. Compile and run. Drag mouse fast and watch the effect. This is motivation for further developments ...

Version 1b: Double buffered graphics to fix Linux glitches in Version 1a. Draw.java: ver.1a + double buffering. Compile and run. Notice that double-buffering eliminates Linux graphics blotch.

Version 2: Persistence of drawing, the underlying data MODEL ...

a) Implement (the VIEW of) freehand drawing as well as straight lines.
b) Consider the possibility that pictures could be a list of Markers (x,y,updown,size,red,gree,blue) connected by lines.

... assuming Marker is defined
private Vector<Marker> picture = new Vector<Marker> ;

As one draws the Markers are put in the picture list.
c) Put this together for VIEW persistence by overriding the paintComponent(Graphics). This method might draw lines between Markers in some appropriate fashion.

      ... 
      Graphics g2 = (Graphics2D)g ; // where g is Graphics
      g2.setStroke(new BasicStroke(...)) ; // size of pen ... ???
      // ... draw with g2 not g ...

Version 3: Saving or Opening user's pictures ...

♦ JavaEditor2009 code sources (in separate window), and some sample functions.

Opening and Saving
JavaEditor.java SAVE menu or toolbar --> "save" line 1827 --> save() method, line 1896
JavaEditor.java OPEN menu or toolbar --> "open" line 1829 --> open() method, line 1855

It should also be possible to save and load the picture as a serialized object! For example ...

   /**
   *  Save the picture assuming fileSpec already known, 
   *  otherwise use saveAs() which employs a FileDialog.
   */
   synchronized void save() { 
      try { 
         FileOutputStream fos = new FileOutputStream(this.fileSpec) ;
         GZIPOutputStream gzos = new GZIPOutputStream(fos) ;
         ObjectOutputStream out = new ObjectOutputStream(gzos) ;
         out.writeObject(this.picture)  // Save the object, serialized
         out.close() ;
      }
      catch (IOException e) { 
            JOptionPane.showMessageDialog(this, 
                      "Cannot save => " + e.toString(),
                      "IO Warning ...  ",
                      JOptionPane.INFORMATION_MESSAGE) ;
      }
   } // end save

In order for this to work the surrounding class needs to be declared with implements java.io.Serializable.

⇑

Week 6 -- More Graphics2D and some Drag-and-Drop Examples

♦ Quiz on Wednesday

Monday's lecture will cover some drag-and-drop principles. A little GUI for experimenting with dropped stuff having a String representation is DropTest.java.

♦ImageZoom GUI demonstration

Modus Operandi

The first mouse click  1  establishes the fixed point on the image.
Pick a point  2  to start dragging the mouse to other points X.
While the mouse is dragged, at any X, we have:

a radial scale factor = r'/r, with fixedpoint at 1
a rotational angle (theta) around the fixed point 1
and the image is redrawn, subject to these transformations

Let up the mouse to discontinue transformations.
A third mouse click resets the image to its original appearance.

To magnify a small feature on a large image, make the first click
to one side of the feature.  Then click on the opposite side of the
feature and drag away from the first click.  Practice makes perfect.

The sources folder shows in a separate window. The ImageZoom.jar is located there. Lecture will relate how user gestures are converted to a Graphics2D rotational transformation and a scale transformation.

There are other effective gestures that can accomplish magnification of a small feature on a viewed image. One is to drag a selection rectangle over the little feature and then use magnification tools to enlarge and possibly enhance the selected feature.

The original intention was to be able to drag a viewed image (not a file containing the image) from one source such as a NASA webpage and drop it on ImageZoom in order to open it in ImageZoom. This involves some kind of "imageflavor" transfer flavor. However the implementation (dating from 2001) no longer works on any platform!. Correction (2/22/2009): ImageZoom does transfer images viewed in Safari, but not Firefox, to itself using D&D on Intel Mac with latest Java version installed. It would be interesting to find out why and fix this. That could be a good little project if someone is interested.

The MVC design for ImageZoom involves data for the image and the state produced by the gestures, a magnified view of the image corresponding to the user's gestures, and the control is afforded via the mouse events.

⇑

Week 7 -- Buffered Graphics Demo and The Chaos Game animated GUI, Project 4

♦ Read the Wikipedia articles on the chaos game and Sierpinski's triangle . Project 4 has these general requirements or intentions:

The GUI program implements the chaos game and the user interacts on the central panel.
The user selects the initial triangle via three mouse clicks on the panel which determine the three vertices of the triangle.
The fourth mouse click chooses the initial pivot point inside (or outside) the triangle.
Then the internal methods play the chaos game and draw the resulting points.
A fourth click (or some other clearing gesture) clears the panel so that the game can be replayed.
The user can set the background and the pen color.

The interaction diagram gives some insight into MVC design for the chaos game. The internal MODEL needs to represent the state of how the user has interacted with the program (1 click, 2 clicks, etc.). The internal Model must store the data (clicks x,y) in order for the program to continue. After the 3rd click, the triangle is determined. After the fourth click the initial pivot point is known. At that point (state #4) the program is free, at last, to compute the chaos game according to the simple algorith, and it does so and then shows the result. Now the program waits for the user to look at the result. The program does not care what the user thinks about the result.

BUT, if the user now clicks on the panel (or uses clear action) the panel clears and then the whole process repeats, starting again in state 0.

The progressive VIEWs might vary. When the user selects the vertices of the triangle they might appear highlighted on the panel. When the triangle has been selected, it might be drawn tentatively (even though it is not technically part of the final picture). Similarly, when the initial pivot point is selected by the user, it might be shown (perhaps to vanish after the result is computed).

The CONTROL involves MouseEvents on the panel. The mouse clicks drive the MODEL form one state to another (1st click, 2nd click, 3rd click, etc.). When the model (via events) has achieved state 4 then serious computation must happen and the result must appear!

⇑

Week 8 -- GUIs with network interactions

This article gives basic definitions for terms associated with interaction design. Interaction over diverse environments (rather than, say, on a single desktop having one presumed user) may require more complex analysis. In particular, network interaction may require modelling more than one user for interactions.

This article gives basic definitions for terms associated with virtual private networks (VPN).

This article describes an architecture for human interaction with a program over a network. The Java Connector object enables the connection.

This portable chat program allows drawing, text and images on a networked whiteboard. The image drop works on latest Java/ Mac but not elsewhere.

♦ (Thursday 2/26/2009) Ports 5001-5005 are said to be open in the lab LAN! Try ChatWriter through one of these ports ;-)

The next project, #5, will involve playing the TIC TAC TOE game over the network. The requirements wil be posted Monday. The next quiz will be a takehome assignment due next Friday: write up an MVC analysis and the interaction scenarios for a networked TTT game.

⇑

Week 9 -- Two-person TicTacToe networked GUI

♦ Project #5 Modify the man-verses-machine TicTacToe game so that one player can start the (Connector) server and join, and then the other human player joins to play the game. Prototype sources are here.

⇑

Week 10 -- Finish Project(s) Week ...

⇑