[ossrp-control] Re: Features So Far

It's also worth noting that the scripting language that a certain screen
reader uses is provided with its own compiler tools right along with the
screen reader.  I'm sure that the open source screen reader will not come
packaged with a copy of Visual C# .NET just in case you need to make those
tweaks <grin>.

Regards,
Jerry



                                                                                
                                                             
                      "Jamal Mazrui"                                            
                                                             
                      <Jamal.Mazrui@xxxxxxx>         To:       
<ossrp-control@xxxxxxxxxxxxx>                                                 
                      Sent by:                       cc:                        
                                                             
                      ossrp-control-bounce@fr        Subject:  [ossrp-control] 
Re: Features So Far                                           
                      eelists.org                                               
                                                             
                                                                                
                                                             
                                                                                
                                                             
                      04/27/2005 05:03 PM                                       
                                                             
                      Please respond to                                         
                                                             
                      ossrp-control                                             
                                                             
                                                                                
                                                             
                                                                                
                                                             




I agree that open source allows programming changes that are not possible
otherwise.  I think programming in a scripting language, however, is
considerably easier ( than in the source language, which I'm guessing will
largely be C# because of Will's proficiency in the C language generally.

A scripting language, for example, does not enforce strict OOP coding, as
.NET languages do.  Also, adding a script is an easier process than
recompiling a whole application, where one has to account for many more,
inter-related files.

I am not advocating a scripting language necessarily at this time, just
expressing the opinion that open source does not accomplish what a
scripting language typically does.

An intermediate approach might be a keyboard macro recorder.

Jamal
-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: Wednesday, April 27, 2005 4:54 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: Features So Far

Hi,

Is a scripting language really necessary?  As far as I know, VBS isn't
being developed further, although it will still continue to be supported
for a while yet.  The main reason that I can see for implementing a
scripting language is the ability to modify the behaviour of a specific
portion of the screen reader's execution path.  With an open source
project, there exists a much better way, and that's to modify the source
code itself, and as it's an open source project, anyone can download their
own sand box copy and modify the code.

Scripting languages generally tend to give you access to more coarse
functionality, which is both a good and bad thing.  Sometimes you want to
play at that level of coarseness, something which access to the source code
allows you to do, but at other times you only want to make very minor
changes, something that access to the source code permits, but scripting
capabilities do not.

So, implementing a scripting language looks a lot of work for relatively
minor gains.  If it was a closed source project, then it would be a good
and valid suggestion, but as it's not the returns you get from it are
fairly minor.

Will
 ----- Original Message -----
 From: Jamal Mazrui
 To: ossrp-control@xxxxxxxxxxxxx
 Sent: Wednesday, April 27, 2005 8:26 PM
 Subject: [ossrp-control] Re: Features So Far

 One exercise I think is useful sometimes is to ask what is not desired.
 Phrased another way, what features of present Windows screen readers do we
 think are not worth emulating?  I do not have ready answers to this
 question myself, but thought it was worth posing, as it can help draw
 boundaries around the scope of the project.

 Also, a topic which I do not recall being addressed specifically is
 whether the screen reader should support a scripting language for
 application configurations.  Is there a new scripting language for
 Longhorn, a successor to VBA?  If there is a built-in scripting language,
 then it may be the easiest language for the screen reader to host for
 configuration scripts.

 Naturally, as much configuration as possible should be implemented without
 the need for scripting.  Some people may even prefer to avoid the
 scripting route entirely.  Thoughts anyone?

 Jamal


 -----Original Message-----
 From: ossrp-control-bounce@xxxxxxxxxxxxx
 [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
 Sent: Wednesday, April 27, 2005 3:02 PM
 To: ossrp-control@xxxxxxxxxxxxx
 Subject: [ossrp-control] Features So Far

 Hi,

 Here's my understanding of the important features that should be
 investigated for version 1.  It doesn't feature everything, but then
 there'll be versions after 1 in which more things can be brought in.

 Functional requirements:
 * ability to read *windows* login screen
 * ability to work with widely used types of applications, e.g. word
 processors, spreadsheets
 * support for TTS engines that use the SAPI interface, as some of these
 provide clearer speech than current formant synthesisers
 * ability to use mouse or equivalent functionality
 * must work with User Interface Automation
 * ability to update components over the web
 * support for Braille devices

 Architectural requirements:
 * based on .Net Framework/WinFX
 * component based architecture

 * Research requirements
 * investigate mechanisms to provide more efficient interaction mechanics
 * investigate techniques to convey all the semantic information contained
 within a GUI through auditory and tactual/haptech transmission media.
 * investigate means for clearer speech
 * investigate perceptual psychology techniques for semantic conversion of
 web based graphical turing tests to text

 Project management requirements:
 * risk analysis
 * avoid scope creep
 * requirements management
 * beta 1 to be made publically available April 2006

 These are fairly high level requirements, and if anyone feels anything is
 being missed or would like to include anything, then say now.

 Will




To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes

Other related posts: