[ossrp-control] Re: Features So Far

If the screen reader is designed with a robust object model that exposes
well-documented properties, methods, and events, then a good scripting
capability should be possible to add as an extension, perhaps via an SDK
(as has been suggested).  I am not that concerned about the screen
reader being written in a proprietary .NET language as long as it can be
recompiled with a freely usable compiler and libraries..  Since
downloading the .NET Framework includes a command-line compiler and the
base classes of the Framework, this should be possible.

Jamal

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Richard Thomas
Sent: Thursday, April 28, 2005 7:05 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: Features So Far


Hi guys;
Who says we can't do both downline?  Remember there will be open source
code 
available and anyone will be welcome to get a copy and develop a script 
language of their  choice.  That's the beauty of open source.  Once the 
program is done, download it, add a scripting language, or just about 
anything else your heart might desire, and bam! an optional method of 
creating development accessibility. The hope should be that many folks 
enhance the program with new and innovative ideas to further
accessibility 
for as many blind folks as possible around the world through the Net.
The 
best ones will, I believe, be encorporated into the root project to
build 
the finest reader available.  there are hundreds of programming types
out 
there who might contribute to an open source project of this type and
even 
the for profit big guys can't match that level of innovative creativity
or 
raw programming power.
Rick of Farmington Mich. USA
----- Original Message ----- 
From: "Sina Bahram" <sbahram@xxxxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Thursday, April 28, 2005 6:27 PM
Subject: [ossrp-control] Re: Features So Far


>I could not agree more with your comments.
>
> I really believe it is an extremely bad idea, not to mention one
> counterintuitive to the idea of open source, to force people to
program in 
> a
> mainly propriotary language to modify something that is supposed to be
> giving them access.
>
> Take care,
> Sina
>
> -----Original Message-----
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Brian
> Sent: Thursday, April 28, 2005 7:57 AM
> To: ossrp-control@xxxxxxxxxxxxx
> Subject: [ossrp-control] Re: Features So Far
>
> I agree. I do not consider a screen reader without the flexibility and
> versatility of a scripting languange a viable option. Certainly not in
a
> business environment wherein custom apps are often used.
>
> If the same flexibility can be provided in other ways that's fine, but
I'm
> no programmer. I am not going to learn .net just to be able to
customize 
> my
> screen reader. I would though learn a subset of .net that relates
directly
> to presenting information speech and Braille.
>
> I disagree with the comments about JAWS scripting. It's the best thing

> about
> the program. Scripting is what sets it apart and has put it at the
head of
> the pack. It has plenty of shortcomings, but many relate to poor
marketing
> decisions, lack of comprehensive support, and lack of scripting
> documentation - which has been somewhat alleviated of late.
>
> -----Original Message-----
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Sina Bahram
> Sent: Thursday, April 28, 2005 12:43 AM
> To: ossrp-control@xxxxxxxxxxxxx
> Subject: [ossrp-control] Re: Features So Far
>
> I definitely want to be able to support scripting
>
> Take care,
> Sina
>
> ________________________________
>
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Jamal Mazrui
> Sent: Wednesday, April 27, 2005 3:27 PM
> To: ossrp-control@xxxxxxxxxxxxx
> 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
>
> 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
>
>
> 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
>
> 


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


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: