1 Here's the readme I provided when I published the sources online: of
2 course, to be accurate it needs to be accompanied by a license.txt file
8 Find further information at www.smowton.net/chris
14 III. Class outline of dasher package
15 IV. Contacting the author
20 This program is free software; you can redistribute it and/or modify
21 it under the terms of the GNU General Public License as published by
22 the Free Software Foundation; either version 2 of the License, or
23 (at your option) any later version.
25 This program is distributed in the hope that it will be useful,
26 but WITHOUT ANY WARRANTY; without even the implied warranty of
27 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
28 GNU General Public License for more details.
30 The complete license can be found in COPYING in the parent directory.
38 This contains the core Dasher source code. It corresponds to the
39 DasherCore package in the original C version of Dasher. By themselves
40 the classes in this package cannot form a completely working Dasher. To
41 produce a working system, one must:
43 a) Implement the CDasherScreen interface (see section III for details)
44 b) Subclass CDasherInput at least once to provide co-ordinates (eg. from
45 a mouse) on demand (again, see details below)
46 c) Subclass CDasherInterfaceBase, specifying the abstract methods of
47 that class. Most of these can be stubbed and still produce a working
48 system, though it may lack the ability to learn from training text, or
50 d) Optionally, subclass CSettingsStore to provide the ability to store
51 persistent settings. If this isn't done and the base CSettingsStore is
52 used, the defaults will be loaded every time Dasher is run.
57 This package contains the classes to complete an implementation of
58 Dasher as a Swing applet, by more or less the means described above. It
59 also provides some extra, optional functionality, such as listening for
60 text events and showing the currently entered text in a text box.
64 * JDasher, which is a subclass of CDasherInterfaceBase and provides
65 methods to retrieve data files from a JAR
66 * JDasherApplet, which sets up a Swing GUI and generates Dasher events
68 * JMouseInput, a subclass of CDasherInput which provides mouse
69 co-ordinates on demand.
70 * JDasherScreen, which implements CDasherScreen and converts graphics
71 primitive instructions to Java AWT drawing commands.
72 * JSettings, which subclasses CSettingsStore to use the Java Preferences
73 class to store persistent settings. The Preferences class in turn defers
74 to the JVM, meaning it will try to use the Registry on Windows, a
75 .javasettings file in Linux, and so forth.
80 This is an implementation of Dasher which provides a network interface
81 based upon XML transactions. The 'screen' (NetDasherScreen) implements
82 CDasherScreen but doesn't really act as a screen; rather it gathers
83 relevant data and sends this to a client, such as the JavaScript client
84 found at www.smowton.f2s.com/jsdasher.html. Similarly, NetInput provides
85 input by interpreting XML documents fed by the client.
87 The net package provides a multithreaded server to host several such
88 Dashers at once. Loosely, the structure is that NetDasherListener is
89 started as the main thread, and this spawns a
90 NetDasherCommandInterpreterThread for every incoming connection it
91 receives. These threads interpret the XML document sent by the client
92 and respond in a variety of ways, usually creating or invoking methods
93 of a NetDasherConnectionHandler (which creates an instance of Dasher,
94 NetScreen and NetInput and acts to pass messages back and forth between
95 Dasher and the network server).
97 These ConnectionHandler objects as well as their associated Dashers are
98 persistent between connections, and so act to provide a continuous session.
100 Typically JavaScript clients will not speak directly to the Dasher
101 server, but will pass requests to a webserver first, since security
102 restrictions typically require that JavaScript does not invoke URLs
103 which are not on the same server as the JavaScript itself.
105 III. Dasher core in detail
106 --------------------------
108 CAlphabet: Represents the alphabet we're currently working with. It it
109 responsible for holding information about how each symbol in the
110 alphabet should be typed, how it should be displayed on screen, and some
111 aspects of how the symbols should be coloured.
113 CAlphabetManager: Carries out certain functions which manipulate the
114 general Dasher state, but depend upon Alphabet data. Example include
115 outputting the appropriate text when the user enters a node, and
116 populating child nodes when required to do so by the Model.
118 CAlphabetManagerFactory: Factory class for the above.
120 CAlphabetMap: Wrapper around a HashMap from a UTF-8 representation of a
121 symbol to its unique integer identifer. This used to be much more
122 complicated, but could probably now be reduced to just a HashMap which
123 would probably be a member of CAlphabet.
125 CAlphIO: Given a list of XML files, parses them for descriptions of
126 alphabets, and uses this to report a list of available alphabets.
128 CAutoSpeedControl: Uses a variety of diagnostic signs to establish
129 whether the user would like to go slower or faster, and controls the
130 Dasher maximum speed appropriately.
132 CCannaConversionHelper: In the C version, provides for conversion from
133 Hiragana to Kanji in Japanese. At the time of writing this was an
134 unstable development feature, and this class is a stub at present in
137 CCircleStartHandler: Provides the possibility of a circular target which
138 can be used to start Dasher.
140 CClickFilter (extends CInputFilter): An input filter which causes Dasher
141 to zoom when the user clicks. It does this by calculating a set of
142 points forming a line between the current position and that which was
143 clicked and adds these to m_deGotoQueue, a list of "pending points"
144 which the Model consults as a potential source of movement instructions.
146 CColourIO: As CAlphIO, but reads colour scheme XML files.
148 CContextBase: Base class of all language models' classes representing
149 some context for predicting input. This is typically used outside the
150 language model so that the rest of the program does not depend upon a
151 particular language model. It exposes no methods, and so contexts cannot
152 be modified outside the language model.
154 CCustomColours: Wraps around a colour scheme object read by CColourIO;
155 used by the View classes to determine how the nodes should look.
157 CDasherComponent: This is a base class for a large number of Dasher
158 components, and provides several basic functionalities, including the
159 handling and creation of events, and the ability to consult and modify
160 the settings store. It provides a default EventHandler which ignores all
161 events, which is designed to be overridden by subclasses. Only
162 subclasses of CDasherComponent can register themselves to listen for events.
164 CDasherInput: This is a base class for some form of co-ordinate input
165 which provides either 1 or 2 co-ordinates. This class is abstract and
166 must be extended if you wish to provide any input to Dasher.
168 CDasherInterfaceBase: This is the central class of the Dasher core. It
169 provides centralised functions which have widespread consequences
170 including Start(), ChangeAlphabet() and so forth. It also provides
171 NewFrame(long) which is the standard way to cause Dasher to update the
172 model and draw a frame. It does not perform much of the functionality
173 itself however; it defers the maintenance of the model to CDasherModel
174 and the drawing of it to CDasherView and its children.
176 It includes a number of abstract methods which are
177 implementation-dependent. These must be implemented to produce a working
178 Dasher, but most can be stubbed safely. The only issue which is
179 genuinely important is to ensure that a CSettingsStore (or subclass) is
180 produced before any CDasherComponents are created (which would depend
183 CDasherModel: This maintains a tree of CDasherNodes, each of which
184 represents a box with a letter in it. It is responsible for deciding
185 when to create new nodes (although it defers the actual act to the
186 AlphabetManager) as well as when to delete old nodes, in collaboration
187 with the View (which informs the Model of situations such as a node
188 being too small to draw, and so a candidate for deletion). It also plays
189 a major role in making Dasher "move" by altering the crosshair position
190 in response to newFrame calls made to CDasherInterfaceBase.
192 CDasherNode: This represents a box with a symbol in it, and is the unit
193 component of the Dasher tree maintained by the CDasherModel. It also
194 posesses a Context object (child of CContextBase) which describes the
195 prediction context for this node (ie. the data the language model should
196 use in deciding its likely successors). Nodes are also aware of their
197 size in terms of Dasher co-ordinates, though not their on-screen size.
199 CDasherScreen: This defines an interface for drawing (or otherwise
200 outputting) graphics primitives. Some class must implement this to get
201 any visual output from Dasher, and an instance of this class must be
202 registered with the Interface by means of its ChangeScreen method.
204 CDasherView/Square: The base and one implementation for a 'view' which
205 is to say a class for visualising the Dasher tree. Whereas the model
206 knows only the nodes' relative probabilities, the View converts these
207 into some visual representation; in the case of ViewSquare, into a set
208 of square boxes. It responds to a Draw() request by translating the
209 Model's data into primitive drawing commands executed by some
210 implementation of CDasherScreen.
212 CDefaultFilter: Default input filter, which simply causes Dasher to zoom
213 towards wherever the user is currently hovering the mouse.
215 CDelayedDraw: Helper class for drawing boxes with a symbol in them
216 without the risk of overwriting symbols by mistake. All text to be drawn
217 is placed on a stack, and at the end of the drawing cycle, and after all
218 other primitives have been drawn, the stack is emptied and its contents
221 CEventHandler: The event handler permits CDasherComponents to register
222 themselves as event listeners. All components register themselves as
223 part of the Component's constructor, though of course this can be
224 overridden. When an event is raised, the HandleEvent method of each is
225 called in turn with the Event as a parameter.
227 The EventHandler does not involve any threading whatsoever, unlike
228 Java's built-in event subsystem. When a Dasher event is raised, the
229 raising method will not continue until all listeners have had their
230 HandleEvent routines called.
232 For the eventuality that a reponse to an event causes another event to
233 be raised, the event handler keeps track of how many events are
234 currently unfinished. If a listener tries to add itself whilst this
235 number is not zero, it goes in a queue. As soon as the last event
236 finishes processing, the Components in the queue are made listeners proper.
238 CInputFilter: Base class of all input filters. These play a pivotal role
239 in the update-model-and-draw frame cycle. They respond to both key
240 presses and mouse clicks by their keyDown methods being invoked, and the
241 drawing of a frame without cue through their Timer method, whose
242 argument specifies the time since the last frame.
244 Typically, the start of a new frame consists of the Timer method being
245 called, which is then responsible for calling the Model's functions with
246 parameters indicating what changes need making.
248 The inputfilter will also be invoked at the very end of the new frame
249 cycle in order to apply any view decorations it wishes to on top of the
250 standard appearance rendered by DasherView. A typical example is drawing
251 a line to the current mouse position.
253 CLanguageModel: This is responsible for Dasher's prediction of what the
254 user is most likely to enter next. It is fed data by having its
255 EnterSymbol and LearnSymbol methods called on Context objects (children
256 of CContextBase), and will have getProbs called to determine the
257 relative sizes of CDasherNodes whenver the tree is expanded by the
260 Details of how the modelling is done is dependent on the language model
261 used. The only subclass included here is CPPMLanguageModel, but a few
262 other possibilities were explored in the original C version and can be
266 IV. Contacting the Author
267 =========================
269 I can be reached on chris@smowton.net, cs448@cam.ac.uk, or
270 chris.smowton@cl.cam.ac.uk.