[brailleblaster] Re: Some design considerations
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 12 Oct 2012 01:13:06 -0500
Hi Vic,
SWT can generate a progress bar. I have figured out how to query
liblouisutdml about the progress of a translation. We'll worry about it
when we get to it.
John
On Fri, Oct 12, 2012 at 02:01:03AM -0400, Vic Beckley wrote:
> John,
>
> What I would expect to see in Windows is a progress bar or a marquis bar. All
> screen readers can give feedback for a progress bar. Maybe you could only
> show it if the processing step was expected to be longer than a certain time
> point. Is such a beast available through SWT?
>
>
> Best regards from Ohio, U.S.A.,
>
> Vic
> E-mail: vic.beckley3@xxxxxxxxx
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Monday, October 08, 2012 4:28 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Some design considerations
>
> 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
>
>
--
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:
