GNOME Bugzilla – Bug 484499
Orca should not braille the node level for every cell in row
Last modified: 2007-10-10 20:28:44 UTC
Steps to reproduce: 1. Launch Thunderbird 2. Arrow among the messages in your inbox Expected results: Orca would tack on the node level at the very end of the braille region. Actual results: Orca tacks on the node level at the end of each and every cell.
Created attachment 96845 [details] [review] proposed patch Currently, _getBrailleRegionsForTableCell() is what tacks on the node. If we only want to tack it on at the end, we should be able to do that in _getBrailleRegionsForTableCellRow() instead -- right?? I grepped for _getBrailleRegionsForTableCell() and found it was called only by _getBrailleRegionsForTableCellRow(). (StarOffice.py has its own methods). Therefore, I think this is a safe change that solves the problem. Will?
> I grepped for _getBrailleRegionsForTableCell() and found it was called only by > _getBrailleRegionsForTableCellRow(). (StarOffice.py has its own methods). This is probably OK, since the self.brailleGenerators table of braillegenerator.py currently does not include _getBrailleRegionsForTableCell. It used to, but I believe that was replaced with _getBrailleRegionsForTableCell when the read row work was done. As an alternative to moving the TREE LEVEL block from _getBrailleRegionsForTableCell to _getBrailleRegionsForTableCellRow, I wonder if adding a new parameter (e.g., includeTreeLevel=True) to _getBrailleRegionsForTableCell might be better? With this, _getBrailleRegionsForTableCell could still behave as a standalone generator (if we wanted it to behave that way at some point in the future). The behavior would be that _getBrailleRegionsForTableCellRow would set the parameter to prevent the output of TREE LEVEL as appropriate. Joanie, what do you think?
I think that makes a lot of sense. It's gotten late on me, but I'll implement your suggestion tomorrow. Thanks!
So it's now tomorrow. :-) I still think it makes a lot of sense. :-) But.... What I wound up doing is make includeTreeLevel=False when we were speaking/brailling the entire row -- with the exception of the last column. That seemed to work swimmingly with the things I tested. However, there was the possibility of the last column not having STATE_SHOWING in which case _getBrailleRegionsForTableCell() would never get called for it with includeTreeLevel == True. I was chatting with Will about how we can most efficiently address that scenario. At the end of the conversation, Will suggested that the original patch was fine and if one day braillegenerator.py once again includes _getBrailleRegionsForTableCell() we'll address this stuff then. Therefore, I'm adding our new [testing required] to the summary.
This is so much better. thanks much
Thanks Mike. Will, okay to commit?
Please commit to trunk and the gnome-2-20 branch and feel free to close as FIXED. Thanks!
Thanks guys. Committed to both trunk and the gnome-2-20 branch. Closing as FIXED.