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 <mailto:Jamal.Mazrui@xxxxxxx> 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