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



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







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]