GNOME Bugzilla – Bug 356060
Provide access to tree item level and state in OOo Navigator
Last modified: 2009-11-09 21:35:32 UTC
The contents of Openoffice.org's Navigator window are arranged in a tree. While Orca does provide access to the item names/labels, it does not indicate the level of the item you are on or the state (expanded, collapsed) of that item. I think having this information would be helpful. Thanks!!
Add accessibility keyword. Apologies for spam.
Mike/Will, what do we want to do with this one?
This seems like standard tree item presentation that we're doing with GTK+ trees. Can you dig into the information we're getting from OOo? Is it possible that it's not giving us enough information to present the info in the RFE, or is it giving it to us in some other form?
The problem here is that the child in the tree widget in the OpenOffice Writer Navigator window is a label not a table cell. Here's the hierarchy: name='Navigator' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOW ING VISIBLE' relations='' +-name='Navigator' role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' re lations='' +-name='Navigator' role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations='' +-name=None role='tree' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWI NG VISIBLE MANAGES_DESCENDANTS' relations='' +-name='Hyperlinks' role='label' state='ENABLED EXPANDABLE EXPANDED SE LECTABLE SELECTED SENSITIVE SHOWING TRANSIENT VISIBLE' relations='' The code in locusOfFocusChanged() in default.py that deals with tree levels (around line 1415) is inside an if clause that goes: if newLocusOfFocus.role == rolenames.ROLE_TABLE_CELL: I tried moving the two lines: oldNodeLevel = util.getNodeLevel(oldLocusOfFocus) newNodeLevel = util.getNodeLevel(newLocusOfFocus) so that they were outside of the if clause, but that fails in util.getNodeLevel() because those labels do not have a RELATION_NODE_CHILD_OF relation (they don't have any relations). Will, is this another StarOffice/OpenOffice bug?
I talked with Will on this yesterday. The plan is to move the two lines: oldNodeLevel = util.getNodeLevel(oldLocusOfFocus) newNodeLevel = util.getNodeLevel(newLocusOfFocus) outside the if clause and also file a bug against OOo, because those labels should have a RELATION_NODE_CHILD_OF relation.
I've filed OOo issue #71430 against this problem and adjusted the summary of this bug to reflect that we are currently blocked. http://www.openoffice.org/issues/show_bug.cgi?id=71430 Patch to default.py to follow...
Created attachment 76334 [details] [review] Patch to hopefully fix the problem once the OOo bug is fixed.
I think the patch looks good. Thanks!
Patch checked into CVS HEAD.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
The underlying OOo bug has been resolved as WORKSFORME, with the comment: "pb -> richburridge: The navigator does not contain a tree but only a tree. So there is no need for a new relation." It's been reassigned to me, but I don't know how to respond. (To be honest, I don't even understand his comment). Will/Joanie, any thoughts on this? How would you like me to reply? Thanks.
(In reply to comment #11) > The underlying OOo bug has been resolved as WORKSFORME, > with the comment: > > "pb -> richburridge: The navigator does not contain a tree > but only a tree. So there is no need for a new relation." Certainly a confusing statement. Maybe you can ask for clarification?
> "pb -> richburridge: The navigator does not contain a tree > but only a tree. So there is no need for a new relation." > > It's been reassigned to me, but I don't know how to respond. > (To be honest, I don't even understand his comment). It's a koan, Rich. ;-) Actually, I think he's just missing a word ("table"). "The navigator does not contain a tree table but only a tree." And that's true. But items in a tree I believe can still have the NODE_CHILD_OF relationship. And we need that relationship in order to provide access to the hierarchical level of the items being displayed. That would be my response.
> Certainly a confusing statement. Maybe you can ask for clarification? I did that. Then... > That would be my response. Thanks Joanie. I've added that to the OOo bug, reopened it and reassigned it to pb. Still blocked.
They seem resistant to fixing this and suggest we get the hierarchy by looking at the parents. :-( As much as we shouldn't have to <strike>hack</strike> special case the navigator window, it seems to me that we could fix this bug on our end if push comes to shove.
Just an update: I tried the following steps using OODEV300_m27 build 9336 on my OpenSolaris box: 1) Create a new document with 4 headings: "This" "Is" "A" "Test" 2) Press F5 to bring up the navigator and then Alt+F6 to give it focus. 3) Arrow up/down the list. Press left/right to expand/contract the "Headings" item. Observe what Orca presents. Here's what I find: 1) When one arrows to the "This" under the "Headings", Orca presents the new tree level information (YEAH!). 2) When one continues arrowing down the headings, the tree level information is not spoken (YEAH!). When one arrows back to the "Headings" item or to some other level, Orca doesn't present the new tree level (DARN!), and it doesn't present the expanded/contracted state of the item (DARN!). 3) When one expands or contracts the "Headings" item using left/right, Orca doesn't present the new state (DARN!). From what I can tell: 1) OOo is now giving the relation node child of relation. Yeah! 2) OOo has put the expandable/expanded states on the nodes as appropriate. Yeah! 3) Ooo is not issuing any events when one expands/contracts the "Headings" item. Darn! I've logged this as bug http://www.openoffice.org/issues/show_bug.cgi?id=92103.
(In reply to comment #16) > 3) Ooo is not issuing any events when one expands/contracts the "Headings" > item. Darn! I've logged this as bug > http://www.openoffice.org/issues/show_bug.cgi?id=92103. This has been marked as FIXED by the OOo folks. I still have no clue to inner workings of the enigma machine used by the OOo folks to describe in which release to expect a fix to appear (they may want to investigate contracting with the National Security Agency for jobs in the encryption department). All I know is that it still doesn't work for me on OpenSolaris 2009.06, OpenOffice.org 3.1.0 OOO310m11 (Build:9399) [CWS:ooo31osol].
Later this week I'll grab 3.2 and see what's up. Changing the status to "to verify"
Just a quick note that Joanie has also verified http://qa.openoffice.org/issues/show_bug.cgi?id=88069 has been fixed in the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]).
(In reply to comment #19) > Just a quick note that Joanie has also verified > http://qa.openoffice.org/issues/show_bug.cgi?id=88069 has been fixed in the > swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me > (300m51(Build:9408)[CWS:swa11y32_2nd]). > As well as http://qa.openoffice.org/issues/show_bug.cgi?id=92103, which is the more relevant bug.
Created attachment 140791 [details] [review] revision 1 This causes us to do the right thing -- and I think handle labels better in general. OOo tends to use labels where any other toolkit would use list items or table cells. As a result, we say "label" a lot -- I'd argue more than we should. For instance, compare arrowing in the "list" on the left in the Writer Options dialog before and after this patch. Anyhoo.... I ran the regression tests. We need to update the tests in general. That said, the only "regression" I'm seeing is expected, namely not saying "label" in one test: - SPEECH OUTPUT: 'Page design label' + SPEECH OUTPUT: 'Page design' Will, please review. (And note that due to a change and another bug in OOo, interacting with the Navigator is slightly different: Now you need to use Shift+F6 to give focus to the Navigator window. I don't see a way to then give focus to the tree. Seems to be a 3.2 issue. I'll investigate further and file a bug as needed. In the meantime, if you click in the tree, you can then arrow and try my patch. :-) ) Thanks!
Created attachment 140932 [details] [review] revision 2 The problem in bug 590682 was also a problem here. Having fixed bug 590682, this bug needs an updated patch. Will please review. Thanks!
Comment on attachment 140932 [details] [review] revision 2 LGTM. Please commit. Thanks for your work!
Thanks! Patch committed to master. Closing as FIXED.