[brailleblaster] Re: Some design considerations

  • From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
  • To: brailleblaster@xxxxxxxxxxxxx
  • Date: Mon, 8 Oct 2012 15:28:29 -0500

Have a look at the last block diagram I posted. How can we tell the user 
that processing is going on and that the application hasn't just frozen?

John

On Mon, Oct 08, 2012 at 01:12:09PM -0400, Franïois Ouellette wrote:
> Chunking input files may be a workaround but will significantly
> increase the complexity of the program when opening documents. We are
> talking seconds of processing here, nothing unusual in the desktop
> computing world. As for UTD, they seem to be the intermediate format
> between the input and the final output, including when users want to
> save their work and continue or re-use the file later. What would be
> the official output format then, if users do not wish to save their
> work in epub or nimas or some other standard?
> 
> F.
> 
> On Sun, Oct 7, 2012 at 10:56 PM, John J. Boyer
> <john.boyer@xxxxxxxxxxxxxxxxx> wrote:
> > Since BrailleBlaster will be showing both print and Braille when a file
> > is opened, it seems best to pass all xml files through liblouisutdml to
> > produce a utd file. This file will then be opened and processed by
> > BrailleBlaster. The only problem is that there may be a few seconds
> > before it becomes available. How can this be made less unpleasant for
> > the user? Once the utd file is available it will be parsed bby the build
> > method in xom. I think we should time this method for a large document
> > to see how fast it really is. It seems to me that the slow performance
> > is really due to the walkTree method and loading stuff into StyledText.
> > Perhaps we can load only a few screenfulls at a time, and load more as
> > the user scrolls.
> >
> > Of course, when a utd file is opened the translation step is skipped. I
> > think that utd files should be referred to in the user interface as
> > working files, without mentioning utd.
> >
> > John
> >
> > --
> > 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: