[orca-list] Thoughts on moving forwards

[Michael Whapples <mwhapples aim com>]

Hello,
I have to agree with some of the comments made, that should there be insufficient people working on orca then 
there is a risk it will go into a spiral of decline, as it becomes less practical for everyday use the less 
people will be using it and the less potential developers. Speaking for myself, at this point when I really 
want to focus on getting work done I now tend to use a computer without Linux on it and so that in itself 
means I am less able to just do some quick bug finding of applications.

I also agree with those that getting into writing scripts for orca can be difficult to learn, may be 
additional documentation is needed. Having done a little poking about in scripts for dealing with a couple of 
bugs, here are some of my thoughts on what might be the important things to document or at least may be help 
form a guide to where people need to be pointed to learn the right things.

From what I know scripts for orca are reactive things, they consist of methods which orca will call when 
particular events occur, where can we find a list of what method name relates to what event? Also it might be 
good to have some sort of guidance on which events are good for tracking what, as I remember sometimes you 
could use one of a few choices, however normally one would be preferable as it is more specific to the case 
you are dealing with and so avoids unnecessary chatter (unnecessary calling of the method and having to 
filter out irrelevant calls). Also it might be worth noting that developers may want to inherit from a 
toolkit or other script rather than the default one should it basically do what they need and only require a 
small amount of customisation, however this is really standard OO programming stuff and so does it need 
repeating?

Important APIs of orca need to be documented. Which APIs do we really need for scripting orca? Ones like 
speech, braille and the main part of orca where things like setting the locus of focus (cannot remember its 
name) come to mind. Are there other parts of orca which scripters need access to frequently?

Scripts are just python code, they can do anything which is valid in python, so use of external libraries is 
likely to be done. There probably are python libraries which will be used more frequently than others in orca 
scripts, what are they? One which comes to mind is obviously at-spi. References to the various documentation 
for these commonly used libraries would be good, particularly if it pointed out which chapters are of most 
interest to orca scripts (eg. with at-spi I think orca scripts tend to be more involved with examining the 
accessibility tree of an application, the event processing is normally done by the core of orca).

May be also, either built into the above or as a separate thing, a few dos and don'ts of scripting might be 
good. While you can do anything which is valid python there is probably good reason why certain things should 
never be done in a script.

I think that covers the basics of what is needed for scripting with some appropriate questions of where can 
further information be found. This may help scripting, but does it help people get into the core development 
of orca? Well one might hope that if people start scripting for orca, some of those will hit issues which 
cannot really be solved by a script but need a fix in the core, if the person is confident in scripting they 
may feel able to at least take a look at the core to track down that bug.

I think that is all I have to say at the moment, discuss.

Michael Whapples