JPT 2.6.0 Applets Page
JPT 2.6.0 Applets Page
This site will be updated as additional applets are available.
To execute any applet, click on its screen snapshot. On each applet page, there is a link to the source files. Most applets are placed directly on the applet page. A few applets are lauched via an auxiliary “Launch” button.
The Expression Evaluation Pane applet permits the user to enter an
expression that will evaluate to one of the types BigInteger,
double, or boolean (true,false), and
then to perform that evaluation.
Back to Top
The Simple Function Builder applet permits the user to define a simple function whose name is placed in the first text box, whose list of function parameters is placed in the second text box, and whose function body is placed in the third text box.
The screen snapshot shows an example function expsin just
before the “Define Function” button is clicked.
The dropdown for Existing Simple Functions shows the names of the functions defined in this session. If a function is selected, then its definition is shown for possible further editing.
The Built-In Functions dropdown shows the functions built into
JPTParser.
These are available for definining simple functions but their names may
not be used as the names of simple functions.
The Special Forms dropdown shows the five special forms
eval, if, let, set,
and random built into
BaseParser.
These are available for definining simple functions but their names may
not be used as the names of simple functions.
In the second screen snapshot, we show the definition of a recursive function
factorial. The recursion is enabled by the special form
if that lets us easily set up the branch between the base case
and the general case of the recursion. The screen snapshot was taken by
first defining the function factorial, then recalling that
definition using the dropdown menu, and finally performing the computation of
factorial(40) in the expression evaluation pane.
Back to Top
The Functions Plotter applet permits the user to plot one or more
functions of one variable by providing a comma-separated list of the
functions names and the limits of the range in x over which to plot.
Optionally, the user can also control the range of y, the x-spacing of
the vertical grid lines, and the y-spacing of the horizontal grid lines.
The colors in which the functions are plotted may also be set by the
user if desired. This applet comes with a tab that contains a
Simple Function Builder so the user can make function definitions
as desired. The screen snapshot shows the plot of exp and
the function expsin illustrated in a screen snapshot
above.
After a plot, you may allow the mouse to move over the plot window and you will then see the x,y coordinates of the point in the panels below. If you click, the x,y coordinates will be printed on the plot itself. You can clear such annotations with the button provided. Finally, you can see a table of all plot data by clicking the plot data button. The data is shown to one pixel precision. To get more precision, use a narrower range of x.
Back to Top
The Playing Cards Demo displays a deck of 52 cards plus 2 card backs and 2 jokers. If a card is clicked with the mouse, it jumps to the top of the heap. If a card is dragged with the mouse, it moves. The demo can show the cards in sorted order or randomly placed as is illustrated by the two screen snapshots below:
In terms of building graphical user interfaces (GUIs), the Playing Cards Demo illustrates many useful techniques.
main method.DirectApplet
as an applet base class.
BufferedPanel
graphics window.
WebImageTools
and how to save references to these images as an array of
ImagePaintableLite
objects.
Paintable
objects to a
BufferedPanel
so that these objects will float above the panel and be able
to be selected and dragged with the mouse.
SimpleAction
and how to turn a SimpleAction into a Java JButton.
HTable
and vertical tables of components using
VTable.
frame methods of
DisplayPanel. ProbStatTools.
The playing cards are found on the JPT web site at:
http://www.ccs.neu.edu/jpt/images/jfitz_cards/
The ordering of the cards is hearts, diamonds, spades, and clubs, followed by 2 card backs and 2 jokers. This ordering is specified in the following text file within that site: imagelist.txt
There are additional “card fragments”
but only the 56 images in “imagelist.txt” are downloaded
into the PlayingCards program.
To obtain all 67 images including the
“card fragments”, use instead the text file:
imagelistall.txt
The site from which the playing cards were originally downloaded is:
We appreciate the public service that the JFitz site performs by making these playing cards available at no charge.
Back to Top
The Tic Tac Toe game is elementary and so provides a simple setting in which to illustrate additional ideas in GUI building. Before further discussion, consider two screen snapshots from the Tic Tac Toe program.
In the first screen snapshot, player X has won the game and the winning sequence is highlighted in yellow. In the second screen snapshot, the game has been played to a tie since neither X nor O has won and no more moves are possible.
The game uses the concept of a tile that has a size,
an object that is painted, and a background color.
In Tic Tac Toe,
there are actually three objects that may be painted in a tile:
the blank object that just paints the background,
the X object, and the O object.
Notice that the same object may be painted on several tiles.
This distinction is important and is reflected in the code.
The three objects that are painted (blank, X, O) are
Paintable
objects that remain the same throughout the program.
The 9 tile objects that are visible in the GUI are
TileBox
objects that can change the internal Paintable
object that they contain and so can change what they display.
As long as the game is not over, when a blank tile is
clicked it will change its contents to an X object or an O object
depending on which player has the next move. Technically, the tile
does not change its identity only its contents.
The tiles are arranged in a 3-by-3 grid using a
PaintableSequence
The initialization code for the sequence creates a 3-by-3 array of
TileBox
objects each with the blank tile as its contents
and “burlywood” as its background color.
Using the move command,
these tiles are geometrically positioned before being added to
the PaintableSequence. Hence the layout of the tiles is handled easily.
The PaintableSequence is in turn placed into a
PaintableComponent.
This class is an extension of the
Java class JComponent and is designed to hold objects
that are Paintable.
Java components tend to be “heavyweight”, that is, they use significant resources.
Using PaintableComponent is more “lightweight” since the work is done
efficiently in the construction of the underlying Paintable. In this case,
instead of needing 9 components, 1 for each tile, we need 1 component that is built with
1 PaintableSequence that manages the geomeric layout of the 9 tiles and the
interaction with these tiles efficiently.
A PaintableComponent is also set up to
permit the easy definition of mouse actions. It is especially easy to define mouse
actions when the PaintableComponent is built from a PaintableSequence.
The mouse code that controls the game is quite simple.
When the mouse is clicked on the PaintableComponent,
several checks are made.
If the game is over or if the mouse has not hit a blank tile,
then the mouse code does nothing.
Otherwise, if the mouse has hit a blank tile, then the
contents of that tile is changed to an X or an O depending on which
player is next. The next player is then switched to its opposite.
After each click, a check is made to see if the game has been won
or if no more moves are possible.
In effect, one can think of the tile grid embedded within the
PaintableComponent as a complex button that
responds to mouse clicks in a subtle fashion that depends on which
particular tile is clicked. This contrasts with an ordinary button
that behaves in the same way no matter where the mouse is clicked
within the button. The mouse click code illustrates how complex
behavior may be coded in a rather simple fashion.
Back to Top
The Concentration game is a game that uses many of the techniques of the Tic Tac Toe game but has more sophisticated behavior. The game board consists of an even number of tiles whose content is initially hidden. The content is arranged in pairs, that is, each content item actually belongs to 2 tiles. When the user clicks a blank tile, its content item will be shown. Ditto, when the user clicks a second blank tile. If the 2 tiles show the same content, then this content will remain visible during subsequent clicks. If not, on the next click, the content of the 2 tiles will be hidden once again, and the process repeats. The goal of the game is to find all pairs so that ultimately all content is visible.
The Concentration game can use 4 kinds of content item: images, shapes, letters, and numbers. The images are obtained from the JPT web site at:
http://www.ccs.neu.edu/jpt/images/concentration
Since it is not possible for an applet to obtain a directory listing of a web directory, we also supply the following file that lists the images to be loaded:
In principle, it is possible to pass parameters to the applet so that the image web directory and image list may be changed.
The content items for shapes, letters, and numbers are generated algorithmically and so do not depend on any web data.
The user is presented with a panel that permits the choice of content item for the game from the 4 options: images, shapes, letters, and numbers. In this panel, the user may also pick the grid size. A button launches an instance of the Concentration game with these options.
The following 4 shapshots illustrate the 4 content item options and the 4 grid sizes.
Images with grid size 6.
Shapes with grid size 5.
Letters with grid size 4.
Numbers with grid size 3.
We will now briefly discuss the 6 Java source files that make up the Concentration game suite. We will proceed from the bottom up.
The Java file
GameShapes.java:
This class manages the creation of the shapes that will be used when the user selects the shapes options.
The Java file
GameImageData.java:
This class manages the string data that holds the image web directory URL and the name of the text file with the list of images.
The Java file
GamePaintables.java:
This class manages the construction and delivery of the
Paintable
objects that will encapsulate the photo images, the shapes, the letters, and the numbers.
The Java file
ConcentrationOptions.java:
This class creates the GUI for the selection of the content items and the grid size and provides a button to launch the Concentration game with the user options in place.
The Java file
ConcentrationGame.java:
This class builds the main GUI for the Concentration game.
As in Tic Tac Toe, the main game panel uses a sequence of
TileBox
objects that are inserted with the appropriate geometric position into a
PaintableSequence.
That sequence is in turn inserted into a
PaintableComponent.
The mouse behavior is attached to this component but can query the sequence as needed.
It is therefore easy to determine which particular tile has been hit by a mouse click
and to program the required Concentration behavior.
The Java file
ConcentrationApplet.java:
This class arranges that a ConcentrationOptions panel is displayed in an applet.
An earlier version of Concentration was released with Java Power Tools 2.3.5. This version has been significantly refactored to use the latest features of JPT and has much cleaner code.
Back to Top
The
SpinningAnimationApplet
animates either a star with 7 vertices or
an image of a downy woodpecker eating sunflower seeds. The fact that the
animation can deal with shapes or images is due the general code on which
the animation is based.
The class
SpinningAnimation
will in fact spin any
Paintable
object.
We happen to choose as examples
a star with 7 vertices and an image of a woodpecker.
The angular step size of the rotation in degrees
and the animation speed in steps per second
are determined by a pair of sliders created using the class
SliderView.
The SpinningAnimation code uses a
SimpleThreadedAction
to easily arrange that the animation runs in a separate processing thread
so that the animation process and the user interactive process will cooperate.
Back to Top
The purpose of the Star Color Demo is to permit the user to
experiment with the
ColorView
widget. This widget displays a color swatch on the left and a color dropdown
list on the right. If you click on the color swatch, you will be shown a
ColorPaneDialog
that permits a new color to be designed using sliders for the red, green, blue,
and alpha (opacity) components. If you click on the color dropdown, you will
see a dropdown list with 142 named colors. The names have more or less become a
standard on the web. The dropdown is editable so color data may also be entered
as r,g,b,alpha in decimal or hexadecimal. If alpha is omitted, it is taken to
be 255 (#FF) which is fully opaque.
This demo changes the fill color of the same
Paintable
star used in the
Spinning Animation.
Back to Top
The purpose of the
CheckerBoard
widget is to permit a user to interactively compare and contrast colors. This widget was designed
prior to the introduction of the pane
ColorPane
that is now used with
ColorView.
A CheckBoard may also be used without the color controls to provide a board for
games such as chess and checkers.
Back to Top
The purpose of the
VisualColorList
widget is to display the named colors with their r,g,b and hexadecimal values. It use is for code
developers who want detailed information about the named colors and who may want to create new
colors as variants of the named colors.
This widget is intended for developers not end users.
Back to Top
The purpose of the
VisualColorSampler
widget is to combine a VisualColorList and a CheckerBoard.
This widget is intended for developers not end users.
Back to Top
The Shape Editor applet permits the user to enter shape data
as a sequence of MOVE, LINE, QUAD,
CUBIC, and CLOSE operations. In the snapshot
below, you see the shape that is constructed by clicking the button
“Sample Shape”. As you can see, one each of the 5
operations is represented. Once a shape has been designed and painted,
the user may drag the vertex points (red) and the control points (blue)
and observe how the shape is transformed. In this snapshot, we have also
chosen the option to paint a sequence of points on the path in yellow, so
the red vertex point squares are overlayed by the smaller yellow path
point squares.
To experiment with the applet, click on the screen snapshot below.
A shape may be specified in the PathListView in the top left
of the panel by selecting one of the two “Winding Rule”
algorithms and by entering the path data using one of the 5
“path node” operations
below. Normally, the first operation should be a MOVE to
set the starting point of the path. If this is not done, the JPT
algorithms in PathList will set the starting point of the
path to be the endpoint of the first operation that is not a
CLOSE. This provides more robustness and flexibility than
what is available directly in the Java class GeneralPath.
While a user is entering data in the PathListView, there
is no automatic repaint of the shape in the graphics window.
Painting based on this user data does not take place until the
yellow button “Paint Shape” is clicked. This design is
intentional to avoid attempts to read the data while it is incomplete.
The 5 “path node” operations are:
MOVE[x1;y1]LINE[x1;y1]QUAD[x1;y1;x2;y2]CUBIC[x1;y1;x2;y2;x3;y3]CLOSE[]
The values above are float but there is no need to append
the "f" required internally in Java. Here are how these operations work.
MOVE operation takes x1,y1 coordinates to specify a
new current position to move to.
LINE operation takes x1,y1 coordinates to specify the
endpoint of a line that is drawn from the current position. Then the
endpoint becomes the new current position.
QUAD operation takes 2 coordinates pairs x1,y1 and x2,y2
to specify the control point, x1,y1, of a quadratic arch and the next
vertex position, x2,y2, that will form the endpoint of the arch.
The arch starts at the current position and then the endpoint becomes
the new current position.
CUBIC operation takes 3 coordinates pairs. The pairs
x1,y1 and x2,y2 are control points that help determine the cubic shape.
The final coordinate pair x3,y3 is the next vertex position that forms
the endpoint of the cubic shape.
The cubic starts at the current position and then the endpoint becomes
the new current position.
CLOSE operation takes no parameters since it will simply
close up the shape with a line (if necessary) drawn to the last position
specified by a MOVE operation. That position then becomes
the new current position.
If you click on the snapshot above to reach the applet and then you click on the button “Sample Shape”, it will be really easy to see how the 5 operations correspond to segments of the shape. Furthermore, by dragging on vertex dots or control dots, you may see the shape transform. Each time the mouse is released, the data in the view to the left is updated.
For convenience, there is also a button “Circle Shape” that will
show a circle of radius 100 based on the Java class
Ellipse2D.Double. You will see that in Java a circle is not
really a true circle. Rather, it is a path constructed from
1 MOVE, 4 CUBIC segments, and 1 CLOSE.
The Shape Editor applet is intended as an experimental tool for understanding the capabilities built into Java for constructing shapes and computing with shapes. These capabilities are packaged in Java Power Tools into several classes:
These classes provide explicit, editable data structure for path information and
path computation. The class PathList combines a
WindingRule object and a sequence of PathNode objects
but does not implement the Java Shape interface. Rather, the class
provides factory methods to:
PaintableSequence
objects that can represent the path list data
structure in a graphics window.
The graphical representation of a path that is shown in the Shape Editor is in
fact an application of the ability of a PathList to create its own
representation as a PaintableSequence.
The PathList class also has methods to locate vertex and control
points based on x,y position information and to edit this internal data. This
facility is what enables the Shape Editor to have smooth mouse interaction with
its graphical representation.
The class AlgebraicArea uses the PathList data
structure to compute the signed area enclosed by a path list or a corresponding
Shape. This computation rests on calculus but since all data is
given by vertex and control points that correspond to moves, lines, quadratics,
and cubics, the calculation actually reduces to relatively simple algebraic
formulas. These tools are used to update the “Signed Area” in the
view.
Using the PathListView panel,
a user may of course experiment with designing shapes with an arbitrary number
of segments limited only by patience. The button “Clear Shape” will
clear the current shape. Then the user may choose a winding rule and enter shape
segments following the operation data format given above. The following buttons
help:
at the right of each path node panel will insert a new path node panel
above the given one.
at the right of each path node panel will delete its path node panel.
at the bottom will append a new path node panel.
at the bottom will delete the last path node panel.
In addition, the user may simply set the number of path node panels using the text field at the bottom and the “Set Length” button. For convenience, if a path node panel is empty, it is ignored in building a path list.
On November 15, 2007, JPT was updated to release 2.6.0d. In this release,
there were significant enhancements to PathList and
PathNode to make it easier to append diffent path data to a
pathlist quite rapidly. In addition, methods to construct the Java code
to create a given PathList or PathNode were
added to support interactive environments. This was intended to be used
in this Shape Editor demo and so a new button to show the Java code that
corresponds to the current path list was added.
Back to Top