GNOME Bugzilla – Bug 487189
Where Am I should present accessible description if it exists
Last modified: 2008-07-22 19:32:44 UTC
The accessible description presents more information about an object. When one does a Where Am I, the description should be presented if it exists. Mike - we need to you spec where in the order of things the description is presented and which specific Where Am I action(s) it will occur in.
I think at the end of the information presented by a single press would be a good place for this information.
Created attachment 98935 [details] [review] proposed patch... maybe... It seems that more often than not, things lack descriptions. As a result, this was hard to test and "get a feel for". Do we *always* want to tack on the description at the end? Do we *always* want to tack it on the same way? Therefore, rather than tack on the description in whereAmI(), I tacked it on via the individual role-specific methods so we can customize it on a case-by-case basis should the need arise. Given the dearth of accessible descriptions, perhaps that was overkill, but anyway.... The one place where descriptions show up pretty reliably is in Firefox 3 (e.g. titles for links get exposed as descriptions, links with tooltips have titles). In testing this seemingly harmless patch there, I would occasionally see the following traceback: Traceback (most recent call last):
+ Trace 177085
consumed = self._function(script, inputEvent)
self.doWhereAmI(inputEvent, False)
return self.whereAmI.whereAmI(obj, doubleClick, statusOrTitle)
where_am_I.WhereAmI.whereAmI(self, obj, doubleClick, statusOrTitle)
self._getObjDescription(obj),
description = obj.description
cache[h].description = description
When this occurred, doing a second whereAmI, produced the expected result. Is this an error on our end, or a bug in pyatspi? (I just installed the latest from trunk and still get the error)
> File "/usr/lib/python2.5/site-packages/orca/where_am_I.py", line 947, in > _getObjDescription > description = obj.description > File "/usr/lib/python2.5/site-packages/pyatspi/accessible.py", line 523, in > _get_description > cache[h].description = description > KeyError: 16000384 This seems like it might be a bug in pyatspi. Eitan, what do you think?
Created attachment 98938 [details] [review] The "We always want to tack on the description at the end" version I was just chatting with Will. Based on Mike's comment and that chat, we always want to tack the description on at the end of our traditional "single click" whereAmI. Given no need for role-specific customization.... (Doesn't solve the traceback with links, however.)
Eitan, any ideas on the traceback in comment #2? Joanie, can we do some defensive coding to allow at least some speech output to work in the face of this traceback?
Created attachment 99036 [details] [review] The "defensive coding" version As Will requested. In testing, we always seem to get it on the second try (no pun intended), so if there's a description to be spoken this version should speak it.
I can live with this if Eitan cannot come up with a fix for pyatspi.
(In reply to comment #7) > I can live with this if Eitan cannot come up with a fix for pyatspi. Well.... Turns out it's not just descriptions. I was looking at the tooltip bug. We don't present tooltips now because of a similar error. I had moved focus to the gnome weather applet and pressed Control+F1 to show the tooltip which would provide the local conditions. In response I got: vvvvv PROCESS OBJECT EVENT object:visible-data-changed vvvvv OBJECT EVENT: object:visible-data-changed detail=(0,0) Traceback (most recent call last):
+ Trace 177493
debug.printDetails(debug.LEVEL_FINEST, " ", event.source)
println(level, getAccessibleDetails(accessible, indent, includeApp))
% (acc.name or 'None', acc.getRoleName(),
cache[h].rolename = rolename
LookupError above while processing event: object:visible-data-changed ^^^^^ PROCESS OBJECT EVENT object:visible-data-changed ^^^^^
I made Orca use pyatspi's caching. The caching in pyatspi's trunk is useless now, and obviously broken. This is what the stack trace suggests. We could turn it off by default, although the next development release of pyatspi will have caching that will rock your world.
So.... Should I still commit the defensive version or the original version or wait?
(In reply to comment #10) > So.... Should I still commit the defensive version or the original version or > wait? > Give Eitan's patch in bug 495077 a try. If it works, toss the defensive version and go with the original version of your patch. :-)
Okay, Eitan's patch does seem to render the defensive coding unnecessary. Yea! Will, does "go with" mean "commit now" or "wait until there's been more testing done with Eitan's patch"? :-)
> Will, does "go with" mean "commit now" or "wait until there's been more testing > done with Eitan's patch"? :-) Sorry - the best thing is probably to wait until Eitan's caching stuff for bug 495077 is committed.
Sounds good, but just for clarification as I think I'm getting tired/scrambled: When I made my comment #12, I also did the following: 1. Obsoleted the "defensive" patch (AKA the third version, which I had not committed) based on your comment #11. 2. Changed the status of the second version of the patch (i.e. the non-defensive one) to reviewed because I thought you had reviewed it. My mistake. Sorry! Along with your comment #13, you re-obsoleted the non-defensive patch (version 2) and changed the status of the defensive patch (version 3) to accepted-commit_now. So.... We are going to wait until Eitan's caching stuff is committed. Once that has taken place, I will commit the second version, correct?
> We are going to wait until Eitan's caching stuff is committed. Once that has > taken place, I will commit the second version, correct? Sorry for the confusion. We will wait for bug 495077 to resolve and the plan is to check in the non-defensive version of the patch.
I just noticed that the patch for bug 495077 was resolved so I have committed the non-defensive version of the patch. Moving to pending.
Thanks. Closing as FIXED.