[ossrp-control] Re: Features So Far

Well, if we were to allow .NET languages to be used, then the compilers are
generally free anyway.  So not really a problem.  And since the "popular"
scripting language is very C-like, allowing people to use C# wouldn't be
much of a culture shock for them.  But again, since only a tiny fraction of
the target users are ever likely to even look at this possibility, it makes
more sense to leave the options as wide open as possible, rather than tying
everyone up in detail at this stage.

All the best,

David


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of
gerald.g.weichbrodt@xxxxxx
Sent: 28 April 2005 12:31
To: ossrp-control@xxxxxxxxxxxxx
Subject: [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

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: