[brailleblaster] Re: Some design considerations
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Tue, 9 Oct 2012 08:36:01 -0500
I am thinking of adding a method to the Java bindings for liblouisutdml
that would return an integer that could be used in the progress bar.
Thus BrailleBlaster would be handling the bar.
John
On Tue, Oct 09, 2012 at 09:22:38AM -0400, Franïois Ouellette wrote:
> A progress bar has to be handled by the process that does the work; if
> we have BB calling liblouis to do a translation then liblouis would
> have to handle the progress bar, which also means it would have to
> know in advance how big is the translation and calculate the scale to
> use for the work. Not a practical approach IMHO!
>
> F.
>
> On Mon, Oct 8, 2012 at 4:54 PM, Michael Whapples <mwhapples@xxxxxxx> wrote:
> > With a progress bar.
> >
> > The question though would be, how can BrailleBlaster know that liblouisutdml
> > is actually still working and not got itself in an endless loop?
> >
> > I don't know how hard it would be to extend the liblouisutdml API to allow
> > for giving translate functions a callback function. This would also need
> > mapping into Java, I imagine this would need some stuff in the C code of the
> > bindings which could call a method of an object.
> >
> > Michael Whapples
> > On 08/10/2012 21:28, John J. Boyer wrote:
> >>
> >> 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:
