![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to README.rtf CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [NeXTSTEP 3.3 examples] / Examples / AppKit / Graph|
Return to README.rtf CVS log | Up to [NeXTSTEP 3.3 examples] / Examples / AppKit / Graph |
1.1 root 1: {\rtf0\ansi{\fonttbl\f1\fnil Times-Roman;\f2\fmodern Ohlfs;}
2: \paperw9840
3: \paperh7740
4: \margl120
5: \margr120
6: {\colortbl;\red0\green0\blue0;}
7: \pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\f1\b0\i0\ulnone\qc\fs36\fc0\cf0 The Graph Example\
8:
9: \b\ql\fs28 \
10: Overview\
11:
12: \b0 \
13:
14: \b\fi560 Graph
15: \b0 plots 2D line graphs of functions of the form y = f(x) and 3D surfaces given by the set of equations x = f(u,v); y = f(u,v); z = f(u,v). Important things that Graph demonstrates are being a source of Object Links, use of the 3D Kit and general NeXTSTEP programming of a small, multi-document application.\
16: \
17: The heart of the application is the
18: \b Expression
19: \b0 class. Objects of this class parse the text of mathematical expressions, and can then evaluate the expressions given a set of values for the variables found in the expression. The Expression class gives Graph a great flexibility in that it can graph novel expressions, intead of being limited to a pre-compiled set.\
20: \
21: The Expression class is built using the Unix tools
22: \b yacc
23: \b0 and
24: \b lex
25: \b0 . The parsing code will probably be confusing for anyone not familiar with these tools. However, the Expression class is designed to have a sufficiently complete interface that it can be used without understanding these internals. Hopefully, between the documentation in the header file and the example usage in this program will allow others to incorporate this object in other applications. The ability to dynamically interpret new expressions should greatly enrich applications which make modest use of formulas.\
26: \
27: The rest of the application is fairly standard NeXTSTEP programming, using the Expression class' abilities to create the data points for 2D and 3D graphs. A Display PostScript userpath is used to draw the line graph, and RenderMan is used to image the 3D surfaces. Both types of documents function as Object Link sources.\
28: \
29: \
30:
31: \b\fi0 Road Map\
32:
33: \b0 \
34:
35: \b\fi560 Expression.m
36: \b0 implement the expression class. They are supported by the files
37: \b expr.ym
38: \b0 (a yacc source file),
39: \b token.lm
40: \b0 (a lex source file) and
41: \b exprDefs.h
42: \b0 (some common declarations shared between these files). The files
43: \b expr.m
44: \b0 ,
45: \b token.m
46: \b0 ,
47: \b y.tab.h
48: \b0 are by-products of the yacc and lex phases of the build.\
49: \
50:
51: \b GraphDoc.m
52: \b0 and
53: \b GraphDoc.nib
54: \b0 implement a 2D Graph document. For each 2D Graph document, a GraphDoc object is created and a instance of the Graph document user interface is loaded from GraphDoc.nib. The GraphDoc object coordinates the user actions performed on the various controls, and uses an Expression object and a LineGraph view to create the graphs requested. Object Link support is implemented in GraphDoc.m.\
55: \
56:
57: \b\fc1\cf1 LineGraph
58: \fc0\cf0 .m
59: \b0\fc1\cf1 implement a view which knows how to draw an xy line plot. It uses Display PostScript userpaths for top performance.\
60: \
61:
62: \b\fc0\cf0 Graph3DDoc.m
63: \b0 and
64: \b Graph3DDoc.nib
65: \b0 implement a 3D Graph document. For each 3D Graph document, a GraphDoc object is created and a instance of the 3DGraph document user interface is loaded from Graph3DDoc.nib. The Graph3DDoc object uses three Expression objects to evaluate the user's equations, a PointMesh surface to render the data and a RotatorCamera to view it. Object Link support is implemented here also.\
66: \
67:
68: \b PointMesh
69: \fc1\cf1 .m
70: \b0 is a subclass of N3DShape, which uses a RenderMan bilinear patch mesh to render a two dimensional mesh of points in 3-space (the sort of surfaces Graph plots).\
71: \
72:
73: \b\fc0\cf0 RotatorCamera
74: \fc1\cf1 .m
75: \b0 is a small subclass of N3DCamera. Its only purpose is to implement the mouse tracking needed to use a N3DRotator to rotate the graph. \
76: \
77:
78: \b\fc0\cf0 ThreeDPanel.m
79: \b0\fc1\cf1 and
80: \b\fc0\cf0 ThreeDPanel.nib
81: \b0\fc1\cf1 implement a very simple accessory panel to allow the user to change a few attributes of the 3D graphs.\
82:
83: \fc0\cf0 \
84:
85: \b\fc1\cf1 GraphApp.m
86: \b0 and
87: \b GraphApp.h
88: \b0 implement the delegate of NXApp. There is one instance of this class in the entire application. This class mostly responds to non-document specific commands, such as putting up the Help or Info panels. It also receives messages from the Workspace Manager to open documents. Finally it is the keeper of the application's NXStringTable, which holds the strings used by Graph, translated to a particular language.\
89: \
90:
91: \b GraphApp.nib
92: \b0 holds the global user interface for the program, such as the menus. It also holds the application's small NXStringTable. These strings are loaded from the file
93: \b\fi0 Graph.strings
94: \b0 .
95: \b Help.nib
96: \b0 and
97: \b Info.nib
98: \b0 hold the user interface for the Help and Info panels.\
99: \
100:
101: \b\fi560 AppIcon.tiff
102: \b0 ,
103: \b DocIcon.tiff
104: \b0 and
105: \b DocIcon3D.tiff
106: \b0 hold the images for the application and document icons.
107: \fi0
108: \b\fi560 Graph.h
109: \b0 is used to make the precompiled header file,
110: \b Graph.p
111: \b0 .
112: \b\fi0 Makefile
113: \b0 ,
114: \b Graph_main.m
115: \b0\fi560 ,
116: \b PB.project
117: \b0 ,
118: \b PB.gdbinit
119: \b0 and
120: \b\fi0 Graph.iconheader
121: \b0 are the usual files that
122: \fi560 Project
123: \fi0 Builder manages.
124: \b Makefile.postamble
125: \b0 and
126: \b Makefile.preamble
127: \b0 contain a few additions to the build process.
128: \b vers.c
129: \b0 is a derived file created by the
130: \b vers_string
131: \b0 command as part of the build process. It contains some useful version information about the program.
132: \fi560 \
133: \
134: \
135:
136: \b\fi0 Highlights\
137:
138: \b0 \
139:
140: \fi560 GraphDoc and Graph3DDoc have the minimal amount of code needed to make a simple document be an Object Link source.\
141: \
142: The PointMesh class shows how to turn a set of data points in 3-space into a surface RenderMan can display.\
143: \
144: The RotatorCamera shows the minimal glue needed to use the N3DRotator class to manipulate an Object. However, there should be more user feedback during the rotation, such as a lightly overlaid virtual sphere to give the user some idea of the rotation axes he is working with.\
145: \
146: GraphDoc's and Graph3DDoc's
147: \b -copyGraph:
148: \b0 methods are a good example of how simple it is to implement copying a view's PostScript or RenderMan into the Pasteboard. Normally this wouldn't be a separate command in the user interface, but this was done because there is no notion of selection in the view where the graph is drawn.\
149: \
150: The GraphApp class is a good example of the minimal amount of glue you need to respond to Workspace messages to open documents (see
151: \b -appOpenFile:type:
152: \b0 and
153: \b -appAcceptsAnotherFile:
154: \b0 ). The
155: \b -appDidInit:
156: \b0 method shows how to open a new document when launched if the user didn't double click on a document.\
157: \
158: GraphDoc has a good use of TypedStreams for reading and writing its documents.\
159: \
160: The save methods in GraphDoc might be helpful in dealing with the various cases of saving.\
161: \
162: LineGraph has a nice example of userpaths. It stores its data in a form that can be directly passed to
163: \b DPSDoUserPath()
164: \b0 .\
165: \
166: In LineGraph.m,
167: \b drawSelf::
168: \b0 and
169: \b drawAxes()
170: \b0 have a PostScript trick of maintaining a consistent line width regardless of how the view has been zoomed.\
171: \
172: Graph takes a fairly minimal approach to localization. Since it has so few strings, the strategy of putting them in one global NXStringTable works fine. Any real application will want to break up their strings into tables along functional boundaries.\
173:
174: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 \
175:
176: \pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\fi560\fc1\cf1 \
177:
178: \b\fi0 Less exemplary parts (exercises for the reader?)\
179:
180: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 \
181:
182: \pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\b0\fi560\fc1\cf1 GraphDoc and Graph3DDoc share a lot of code. Some common functionality could certainly be factored out into an abstract super-class, eliminating the current code duplication.\
183:
184: \b \
185:
186: \b0 Graph needs some good icons for itself and its documents!\
187:
188: \b \
189:
190: \b0 A SplitView couple be used to enlarge the viewing area of the graphs. I think it would be best to slide the lower half of the window down instead of covering it from top to bottom, since the parameter sliders are more useful than those controlling the domain.\
191:
192: }
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.