[brailleblaster] Re: thoughts on design
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Fri, 19 Nov 2010 12:29:07 -0600
Sounds good John. Happy Java-ing.
--le
----- Original Message -----
From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Friday, November 19, 2010 10:38 AM
Subject: [brailleblaster] Re: thoughts on design
This sounds very good. Jedit in particular might be helpful. I'll
certainly have a look at the article.
Meanwhile, I'm pursuing the idea of expresing BrailleBlaster design in
Javaese, since that is the programming language we are using. Top-level
design would be expressed in terms of packages which group together
functions which are either related or can be grouped for convenience.
i'm thinking of concentration my own Java coding efforts on a package
called org.brailleblaster.liblouisutdml This would include everything
related to interacting eith the liblouisutdml library, such as calling
the methods in the bindings, analyzing log files, displaying
configuration settings, etc.
John
On Fri, Nov 19, 2010 at 08:01:34AM -0800, Chris von See wrote:
> 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.java
> >which mediates between the Java code and the underlying platformj.
> >There
> >is 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
> >trees
> >and modifies them according to user input. Creating the JDOM trees
> >should probably be in a different package. Producing output should
> >also
> >be in a different package. The editor does input and output by calling
> >methods in these packages. Other functions of the editor are to
> >offer in
> >interface 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,
> >data
> >encapsulation, utilities, etc.
> >
> >John
> >
> >On Thu, Nov 18, 2010 at 07:55:05PM -0600, qubit wrote:
> >>Greetings. I have just reread the brailleblaster specification
> >>document and
> >>also 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
> >>classes
> >>can 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 to
> >>separate 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 their
> >>interfaces -- 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 display
> >>window for either the daisy or the braille document.
> >>Then class DaisyDoc and class BrailleDoc can define a data member
> >>of type
> >>Display.
> >>
> >>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 is
> >>all that is really necessary.
> >>
> >>PS: I was also tempted to try the old fashioned CRC cards approach to
> >>defining 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
> >
> >
>
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
Other related posts:
