GNOME Bugzilla – Bug 433398
Orca does not provide access to the state of checked menu items in OOo
Last modified: 2008-03-18 17:59:02 UTC
Steps to reproduce: 1. Get into OOo Calc 2. Navigate to the Window menu, select Freeze, and press Enter 3. Navigate to the Window menu, select Freeze Expected results: Orca would speak and braille the checked state of Freeze Actual results: Orca does not speak or breaille the checked state of Freeze. This information is getting exposed: +-name='Freeze' role='menu item' state='CHECKED ENABLED FOCUSABLE FOCUSED OPAQUE SELECTABLE SELECTED SENSITIVE SHOWING VISIBLE' relations=''
Created attachment 87082 [details] Orca debug output whilst testing for this problem. I'm testing this on OOo Calc version: openoffice.org 2.2.0-1ubuntu3, Tue Apr 10 21:51:38 UTC 2007. The Windows->Freeze menu item does not visually have any indication for me that this is a checkable menu item (i.e. like the little tick mark that Gtk+ uses). Also looking at that menu item with at-poke, I see no indication that there is a CHECKED state (I ran it twice, before and after selecting the menu item). I then ran latest Orca against it. I used Alt-w to bring up the Windows menu; then some Up arrows to get to the Freeze menu item. Then I hit Return. I did this twice (see the attached debug.out). There is a CHECKED state for the "object:state-changed:selected" event for the "Freeze" menu item (line 1586), but there is not a CHECKED state for the "object:state-changed:focused" for that menu item (line 1593). It's the latter event that we use to speak/braille the menu item. The onStateChanged() method get's called for "object:state-changed:" events. We override this in the StarOffice.py script. We could add something in there I suppose to try to catch and handle this, but to me, it looks like YAOOoB and we should get them to fix it. The CHECKED state should persist into the "object:state-changed:focused"event. Thoughts?
Created attachment 87084 [details] Joanie's debug output whilst testing for this problem I don't see the checkmark (or any indication that one is a possibility) when it's not checked. However, when it's checked, on my machine that state does persist in both the state-changed:focused and the focus: event in addition to the state-changed:selected event. As for versions, seems I've got you beat by 18 seconds ;-) openoffice.org 2.2.0-1ubuntu3, Tue Apr 10 21:51:20 UTC 2007. Early bird catches the state? ;-)
The time difference is prolly cus I'm running on a 64 bit machine (different Ubuntu distro). Okay, I'll keep looking. Thanks.
I just tried this in a 64-bit install of Feisty -- with matching times. :-) The CHECKED state persisted in the object:state-changed:focused event there as well.
Joanie and I discussed this yesterday. The "trick" is to make sure that a cell in the spreadsheet has focus before you select the Freeze menu item. Knowing that, I can now reproduce this problem.
And the other thing (which wasn't obvious to me) is that the Freeze check box won't get checked if the cell that has focus is A1. Any other cell is good to go.
I ended up testing this with the "Normal" menu item under the "View" menu in OOo Calc. Here's the event: OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='soffice.bin' name='Normal' role='menu item' state='CHECKED ENABLED FOCUSABLE FOCUSED OPAQUE SELECTABLE SELECTED SENSITIVE SHOWING VISIBLE' relations='' Now the problem here is that the role of this menu item is "menu item" (ROLE_MENU_ITEM) rather than "check menu item" (ROLE_CHECK_MENU_ITEM). The __init__ method in speechgenerator.py uses the role name to determine which method deals with objects of that role. _getSpeechForMenuItem() deals with "menu item"'s and _getSpeechForCheckMenuItem() deals with "check menu items". _getSpeechForMenuItem() doesn't do any special tested to see if the state of the menu item is checked because "check menu item"'s normally take a different path. So... 1/ I reckon I should be filing YAOOoB for the wrong role of these critters. 2/ Should i be adding some code into _getSpeechForMenuItem() to see if the CHECKED stated is set and speaking/brailling "checked" if it is?
> 1/ I reckon I should be filing YAOOoB for the wrong role of these critters. > 2/ Should i be adding some code into _getSpeechForMenuItem() to see if > the CHECKED stated is set and speaking/brailling "checked" if it is? Both sound like the right thing to do. #1 for sure because it seems like an OOo bug. #2 because I suspect we'll run into other toolkits that have the same identity crisis with checkable menu items.
I've opened OOo issue #76926 on this. http://www.openoffice.org/issues/show_bug.cgi?id=76926 I'll now look to see if I can generate a patch for this in _getSpeechForMenuItem().
Created attachment 87485 [details] [review] Patch to workaround the problem. The patch provided a workaround for the problem. In _getSpeechForMenuItem() in speechgenerator.py, we need to test if one of the states is CHECKED. If it is, then add that in to the list of speech utterances. Note that we can't tell if this is a "check menu item" that is currently unchecked and speak that state. Similar changes in _getBrailleRegionsForMenuItem() in braillegenerator.py. Not committed yet. Mike/Joanie, let me know if this is an okay fix. The real fix would be for the OpenOffice folk to fix their issue.
Just tried it. Works very nicely. Also makes the items in OOo's View menus much more accessible!
Thanks Joanie. Okay, I've committed the patch and closed as FIXED.
This seems to be working nicely as far as we can get it. It will be nicer when we actually know that this is a check menu but until OO fixes the bug I'd say go ahead and check this in.
(In reply to comment #8) > > 1/ I reckon I should be filing YAOOoB for the wrong role of these critters. > > 2/ Should i be adding some code into _getSpeechForMenuItem() to see if > > the CHECKED stated is set and speaking/brailling "checked" if it is? > > Both sound like the right thing to do. #1 for sure because it seems like an > OOo bug. #2 because I suspect we'll run into other toolkits that have the same > identity crisis with checkable menu items. > I spoke with Malte Timmerman about this at CSUN 2008. The problem is that every single menu item in OOo can be a check menu item. That is, even OOo doesn't make a distinction in its own code. The only way you can tell is via the CHECKED state. Visual inspection of the menu items also makes it impossible to tell if they are check menu items when they are unchecked. So, I guess what we're doing is adequate under the conditions. As a result, I tended to agree with Malte that it would be OK to close the bug. The only possible solution I can think of is to request that OOo create a brand new check menu item role in their toolkit and then modify all of their checkable menu items to implement this new role. I'm not sure that is a feasible solution, but you might consider asking that on the OOo bug if there is strong outcry that the current solution is not acceptable.