Re: [orca-list] What I can do for orca

[Michael Whapples <mwhapples aim com>]

OK, I have done some more reading, looked a bit at the default script 
and am itching to get working. As scripts seem to be the heart of where 
processing is done (I mean that the rest seems to be more concerned 
about handling things for scripts, passing events to the right script, 
giving scripts a common interface for speech output, etc) I guess 
scripts are a good place to begin and as I get to know from that what 
does what expand from there.

Now the question is what might be the best way to play with orca code to 
get really familiar? Find a bug which looks like it should be simple to 
solve (I think looks is the word which worries me there, what might look 
simple from the outside may not turn out that way) or create a simple 
application designed to be inaccessible and try and script it (I sort of 
think back to a video I found online where Willie Walker was giving a 
presentation on orca scripting and scripting gaim, may be the 
application I could do would just keep adding text to a text box and the 
script should have features to alter how orca behaves as it updates or a 
key binding for speaking last line, etc).

Michael Whapples
On 02/08/2010 02:39 PM, Willie Walker wrote:
> > > http://live.gnome.org/Accessibility/PythonPoweredAccessibility
> > > http://www.linuxjournal.com/article/9991
> > > http://library.gnome.org/devel/accessibility-devel-guide/nightly/
> > Thanks for those links, I have read the first, think I understand it. 
> > Looked a bit at gedit with accerciser. I hope that the number of 
> > nodes in a at-spi tree won't be too much of a problem. I guess orca 
> > mainly deals with nodes close to the focus and so doesn't need to 
> > deal with very long paths, is this right?
>
> Orca tends to be driven primarily in response to user actions.  As a 
> result, it tends to stay relatively isolated to areas of the tree that 
> involve changes to the keyboard focus.  However, other aspects of 
> Orca, such as the flat review feature, may deal with larger spans of 
> the tree.  In theory, the tree might be infinitely large -- the fear 
> of infinity is instilled in programmers in the first "Programming 101" 
> course they took in college. So, we cry "OH NO! INFINITY! WE WILL 
> DIE!" if we can ever possibly think that something might theoretically 
> approach infinity. In practice, the object tree is somewhat limited to 
> 10's or 100's of nodes because we're dealing with user interface 
> objects. So, the fear of infinity might lurk and we can (and do) 
> protect against it.  But, needlessly fretting over it will cause our 
> fingers to stop working and we will throw our hands up in failure.
>
> > > Once you are familiar with the kinds of things applications give you 
> > > via the AT-SPI, I'd suggest digging into Orca.  The Orca internals 
> > > docs at the following URL are a little dated, but give you the 
> > > general idea:
> > >
> > > http://git.gnome.org/browse/orca/plain/docs/doc-set/internals.pdf
> > Any chance of a HTML version, or will I need to rely on PDF 
> > conversion tools to get something I am more comfortable reading?
>
> There is 
> http://git.gnome.org/browse/orca/plain/docs/doc-set/internals.html.  
> Note that you are probably best off doing a git pull of orca and 
> reading the document locally than via the git web interface.
>
> > > Note that we created a lot of Orca with minimal resources.  My motto 
> > > was "let the user experience drive the architecture, not the other 
> > > way around."  As a result, I veered away from the school of 
> > > astronautical architecture (i.e., paralysis by analysis) and stayed 
> > > closer to the school of practicality.  In addition, when faced with 
> > > some toolkit implementations that were perhaps a bit buggy or 
> > > provided their own unique interpretation of the AT-SPI 
> > > specification, we had to make things work regardless of the bad 
> > > taste those toolkits left in our mouths (and unfortunately the code).
> > I guess an example might be java and non-alphanumeric keys. I suppose 
> > I need to view it as a user (shouldn't be too hard as I am a orca 
> > user) and make it that if I want to be perfectionist then make it 
> > perfectionist for the user rather than the technicality. I don't know 
> > if it is fair, but comparing orca to LSR, I never got on with LSR, I 
> > felt it didn't really try and focus on making the system usable for 
> > me, orca feels much more focused.
>
> Exactly - our modus operandi has typically been to work for the user 
> experience first and give the implementation a close second.  Note 
> that this doesn't mean do a bad job on the implementation.  It just 
> means you sometimes have to think a little harder and you also 
> sometimes need to compromise.
>
> > > Note that working on Orca also can mean working on *everything*.  
> > > You may need to become expert in someone else's code outside Orca in 
> > > order to debug problems since bugs often lie in the applications and 
> > > toolkits.  So, you need to keep a sense of humor and steer clear of 
> > > that sense of despair to the best of your abilities.
> > I guess what I was getting at saying I want to focus on orca is to do 
> > with my skills, not knowing C will limit my ability to try and dig 
> > into other code (eg. gecko) to find and fix bugs. Yes I am prepared 
> > to help resolve issues lying else where, its just I don't know how 
> > much I could do.
>
> Understood.  Just be prepared for the real world -- you will find bugs 
> in other applications and you will log bugs against them.  Because 
> many mainstream developers are still ignorant about accessibility, you 
> will be guaranteed in 90% of the cases to get a response of 
> "Duh...what?" if you get any response at all.  So, putting on our 
> other hat as educators, we need to work with the mainstream developers 
> to educate them and teach them how to fish.  Like everyone everywhere, 
> some people are wonderful, some people don't care.  I liken it to 
> behavior around handicapped parking spots.  There are those who 
> respect handicapped parking spots, those who violate them 'just this 
> one time' because they are in a hurry,  and those who flagrantly 
> choose to violate human rights because they are self-serving chumps.  
> In all cases, I believe patience and education are the key to success 
> (and I admittedly sometimes lose my patience).
>
> Will
>
> > Michael Whapples
> >
> > > Will
> > >
> > > On Feb 6, 2010, at 4:18 PM, Michael Whapples wrote:
> > >
> > > > Hello,
> > > > After all that has been said recently and after considering what 
> > > > even I have said about ensuring the future of orca, I felt its time 
> > > > to roll up my sleeves and use the skills I have for some good.
> > > >
> > > > Before I begin I feel it probably is best to be open on what my 
> > > > situation is so that either I don't say I can do more than I can or 
> > > > so that others don't get the impression I will be a knight in 
> > > > shining armour and expect too much from me.
> > > >
> > > > All effort I will be putting into orca will be purely voluntary 
> > > > although I should be able to commit a reasonable amount of time to 
> > > > orca at the present moment (possibly enough to be considered 
> > > > full-time) as I am not in employment. This does lead to some of the 
> > > > reasons why I am wanting to help orca. There are the personal 
> > > > reasons, I find Linux/unix a good system to use and that it 
> > > > probably is the correct operating system for me and it would be a 
> > > > sad loss if orca were to drop into a unmaintained state. Other than 
> > > > the personal reasons, I do have possibly slightly more greedy 
> > > > reasons, I am looking for employment in software development and it 
> > > > has been suggested to me (I agree as well) that it may be worth me 
> > > > working on opensource projects in the meantime as generally 
> > > > employers say I lack experience for them to see what I have 
> > > > achieved in the past. Regardless of if the second set of reasons 
> > > > achieve what they intend to, personal reasons is enough to motivate 
> > > > me on this, the second set is more to warn that at some point I may 
> > > > end up having to lower (I don't intend to abandon orca, its just my 
> > > > free time might be less) my input should employment be found.
> > > >
> > > > Now to my skills and what I could do for orca. I am a python 
> > > > programmer (I suppose a good start), and have been using Linux for 
> > > > some time. I would say I have a reasonable knowledge on common 
> > > > issues of the accessibility infrastructure of gnome (enough to work 
> > > > out what might be causing the problem), but I don't know a great 
> > > > deal with the internals of this stuff (I guess I am saying I am not 
> > > > willing to step into other parts of gnome accessibility at the 
> > > > moment, orca is probably enough to start with). Some things I am 
> > > > thinking of which I know about which may be useful for orca 
> > > > development, brltty (I think some time ago I did write a small 
> > > > application for myself which used brltty python bindings), liblouis 
> > > > and its python bindings, speech-dispatcher and python bindings, 
> > > > gobject (may be not used directly but I guess many components orca 
> > > > uses are based on gobject) and cython (a fork of pyrex for creating 
> > > > extensions for python in C).
> > > >
> > > > OK, looking at that lot of skills, yes probably really time to get 
> > > > on and do something. May be I could ask those knowledgeable in 
> > > > orca's code (probably Joanie and Will) where should I start on 
> > > > learning about developing orca? May be a start of a very general 
> > > > overview (what is the very heart of orca, how much is done by 
> > > > scripts, etc). Also when learning about scripts, which ones may be 
> > > > simpler to start with to learn about scripting and then once I am 
> > > > knowledgeable I can tackle the others. Probably once I get going 
> > > > with reading orca's code I will get to understand about using 
> > > > at-spi, but is there any good documentation for getting started 
> > > > with developing at-spi applications? The final question at the 
> > > > moment, should I really wait until the at-spi-dbus stuff is done or 
> > > > get going now? I mean by that, how big are the changes between orca 
> > > > in 2.28.x and after the dbus work?
> > > >
> > > > Michael Whapples
> > > > _______________________________________________
> > > > Orca-list mailing list
> > > > Orca-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/orca-list
> > > > Visit http://live.gnome.org/Orca for more information on Orca.
> > > > The manual is at 
> > > > http://library.gnome.org/users/gnome-access-guide/nightly/ats-2.html
> > > > The FAQ is at http://live.gnome.org/Orca/FrequentlyAskedQuestions
> > > > Netiquette Guidelines are at 
> > > > http://live.gnome.org/Orca/FrequentlyAskedQuestions/NetiquetteGuidelines 
> > > >
> > > > Log bugs and feature requests at http://bugzilla.gnome.org