[ossrp-control] Re: Features So Far

What popular scripting language is very C-like?  Most scripting
languages of which I am aware are more like Basic than C.  I think this
is at least partly because C tends to be more cryptic, case-sensitive,
kkeen on punctuation symbols,etc.--qualities that make it less friendly
to higher level programmers who appreciate scripting languages.

I agree that only a small percent of people would make use of a
scripting capability.  Also, since JAWS, as the most profitable product
of Freedom Scientific, is likely to have a Longhorn version, that screen
reader will be available for those with an interest in scripting to
address unusual circumstances that other configurability cannot
practically address.  Though this approach is not free, I think the
specialized skil and circumstances that lead to scripting are more
likely to have financial support to cover the cost of a commercial
screen reader.

Jamal



-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of David Lant
Sent: Thursday, April 28, 2005 10:13 AM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [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


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: