For some ideas on designs, you might want to consider looking at the source code for some very good existing editors, or even basing BrailleBlaster on an existing product such as Eclipse (there are already many third-party products based on the Eclipse framework).
The article at http://stackoverflow.com/questions/58671/example-of-modern-text-editor-architecutre recommends taking a look at SharpDevelop (written in C#, I'm guessing), jEdit (written in Java) and OpenKomodo (written in Python and C++, I think), all of which are IMO very good editing environments. There are links in the article to the sites for the various recommended editors, and it should be pretty easy to find the source code. I've not looked at their source code myself, but it may be possible to repurpose some or all of the code for BrailleBlaster (check the licenses) - jEdit, for example, has a pretty powerful API, and you may even be able to just write a few jEdit plugins to do some or all of what you need to do. Of course, all of the products I've mentioned are very feature-rich, and most of the features may not be appropriate for your end user base; the Eclipse framework allows you to use as much or as little of the framework as you want, but I'm not sure about the other products.
Cheers Chris On Nov 19, 2010, at 6:18 AM, John J. Boyer wrote:
Laura, After reading your message I had another look at the claasses in org.eclipse.swt.widgets There is already a class called Display.javawhich mediates between the Java code and the underlying platformj. Thereis also a class called Shell.java which contains top-level methods for working with windows. I think we could learn a lot by looking at this package. I wonder how ViewPlus went about the design of TTS. Speaking in terms of MVC, the specifications seem to deal mostly with the view. The model for the editor i JDOM trees and documents. and the code that creates them. SWT may have a class that we can use as the Controller. Of course, liblouisutdml is also part of the model, but it is outside Java, soit is more or less a "black box". It has enough functionality so we should never have to call liblouis directly.We are not really dealing with a Daisy document and a braille document.We are dealing with a single UTDML document, which is displayed using two windows, DaisyWindow.java and BrailleWindow.java.The editor perform multiple functions. Primarily, it displays jDOM treesand modifies them according to user input. Creating the JDOM treesshould probably be in a different package. Producing output should alsobe in a different package. The editor does input and output by callingmethods in these packages. Other functions of the editor are to offer ininterface to settings and help packages.I think that in terms of Javaese, the real top_level design should be in terms of packages. Classes perform subfunctions in these packages, dataencapsulation, utilities, etc. John On Thu, Nov 18, 2010 at 07:55:05PM -0600, qubit wrote:Greetings. I have just reread the brailleblaster specification document andalso the flurry of mail on possible designs and have the following preliminary comments. (Now it's my turn to make a fool of myself...*smile*)It has been my experience that classes are chosen as types for entities that are operated on in the program. The choice of how much complexity to put in each class depends on the spec, and the division of labor between classescan make or break a design (or the programmer*smile*).John's proposal to define a class for the daisy document and another for the braille translation is feasible, but I think some work needs to be done toseparate out any complexity so as to keep the design simple.Here I took a flight of fancy and defined a class Document with file name, I/O details, etc, and create subclasses DaisyDoc and BrailleDoc with theirinterfaces -- however, this doesn't work well because 1. each DAISY file is tethered to a single braille translation and 2. most of what I put in class Document had to be redefined in the subclasses.This led me to define a Display class to maintain the details of the displaywindow for either the daisy or the braille document.Then class DaisyDoc and class BrailleDoc can define a data member of typeDisplay. Ok, I am typing this on the fly, but you get the idea.Another point: If we borrow editor code from another project, they will certainly have already broken down the xml file into a DOM, so really, providing a high level interface and calls to liblouisutdml and liblouis isall that is really necessary. PS: I was also tempted to try the old fashioned CRC cards approach todefining the structure of this program, but I find a more heuristic approach can often yield better results. However, the CRC approach takes the source spec and runs it through some processing to remove superfluous words and then take the significant words that remain and design roughly as follows:adjectives convert to type or class names; nouns convert to object or data names; verbs become methods.I personally have not used this approach, but it was popular for a time.Comments? --le-- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities
