[orca-list] Thoughts on moving forwards
- From: Michael Whapples <mwhapples aim com>
- To: orca-list gnome org
- Subject: [orca-list] Thoughts on moving forwards
- Date: Tue, 6 Dec 2011 10:54:10 +0000
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
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.
] [Thread Prev