GNOME Bugzilla – Bug 574720
Table Navigation Keys for OpenOffice Writer
Last modified: 2009-11-09 21:35:12 UTC
Orca currently uses the shift-alt keys to navigate both vertically and horrizontally in HTML tables with the Firefox browser. I would like to see the same thing in documents that are processed by OpenOffice Writer. At present, the only way one can navigate around tables in Writer is by pressing the tab key to jump from field to field or use the normal arrow keys. This does not work well for larg multi-column tables and you want to navigate down a single column. I would suggest as defaults to use the same shift-alt key combinations for consistency with Firefox.
Created attachment 135287 [details] [review] part 1 - revision 1 For the purpose of testing and for Will to review, I'm doing this in parts. Part 1 is to just get it working, namely: 1. Structural navigation can be enabled/disabled in OOo with Orca+Z. It is disabled by default in OOo because, unlike in Gecko, odds are that you'll want to type. :-) Mind you right now we don't have structural navigation by headings, etc. in Writer. But one day we will. So IMHO a sane default/starting setting is off. 2. Alt + the arrows move by cell, Alt + Home/End move to the beginning/ending of the table respectively. 3. We announce things as we do in Gecko (so we speak the row and column numbers - rather than cell A1, we announce the span of cells if the cell span is greater than 1, we announce the edge of the table, etc.). Note that this patch does not impact how we present cells otherwise; only when using structural navigation by table cell. What this patch lacks is the ability to adjust the preferences. That will be part 2, once part 1 seems in order. Part 3 will add in support for presenting the dynamic row and column headers when navigating. I reserve the right to swap parts 2 and 3. :-) Will, please review part 1. Assuming it doesn't suck too badly, I am thinking it might be nice to get it checked in for the 2.27.2 release with the understanding that parts 2 and 3 will follow as part of 2.27.3. That way more users will have the opportunity to pound on it and comment about what isn't quite right in the meantime. Thoughts? Thanks!
I think part 1 looks fine and say check it into master. Thanks!
Thanks Will. Part 1 committed to master. Steve, if you could start testing it that would be great. Thanks!
It doesn't seem to be working for me. I just opened up a Word document here which I know to have a table in it. Without any special keys, I could arrow around in the document and Orca announces that I got inside the table. When I pressed the normal arrow keys while inside the table, the keys act as they did before; I expected this to be the case - no problem so far. But then I tried the Orca + Z key combination, it just inserts the letter z into the document. I thought the Orca + z key would turn on the new feature. I pulled my current version of Orca from git yesterday June 3rd and when I check the version with 'orca --version, I get 2.27.1pre. Is this the newest version?
Created attachment 135999 [details] Debug listing This is a debug listing while running OO Writer under Orca and invoking the insert+z keys. A couple times earlier, I lost Orca completely so captured the log for any clues. Speech was not lost this time while debugging. I did not apply the patch because I thought it was already committed to git. BTW, I'm running OO 2.3.0 Build 2.3.01 from Dropline-Gnome.
(In reply to comment #4) > before; I expected this to be the case - no problem so far. But then I tried > the Orca + Z key combination, it just inserts the letter z into the document. > I thought the Orca + z key would turn on the new feature. It should. It does for me. I just verified it in a clean install of Orca. > I pulled my current version of Orca from git yesterday June 3rd and when I > check the version with 'orca --version, I get 2.27.1pre. Is this the newest > version? 2.27.2 is the current version. This change was part of the 2.27.2 release. When you built Orca, I assume you did an autogen. If so, I'm not sure what to tell you, but it doesn't look like you have the current Orca.
Created attachment 136095 [details] Debug listing created on June 7th I am now running Orca 2.27.2 and the default hotkey of insert-z works; it speaks the current status of structural navigation as expected. But the alt-arrow keys do not yield anything.
In further detail for my debug listing, I started Orca with the debugging enabled, alt-tabbed to my file browser window where I selected the document to be opened. Upon enterring Oo Writer, I pressed down arrow a few times to get inside the table. I then pressed the Orca + z keys to turn on structural navigation. That feature appears to toggle on and off as expected. but after turning it on, I pressed alt-right arrow four times in succession and then pressed alt-left arrow four more times, during which time I heard no speech. I should also note here that once these alt-arrow sequences are taken, I no longer have any speech when I use normal arrow keys to move around in the document. I think that symptom happens even before this recent change though.
(In reply to comment #7) > Created an attachment (id=136095) [edit] > Debug listing created on June 7th > > I am now running Orca 2.27.2 and the default hotkey of insert-z works; it > speaks the current status of structural navigation as expected. But the > alt-arrow keys do not yield anything. > When I stated above that it was alt plus the arrow keys, what I meant to state was that it was alt + shift plus the arrow keys. In other words, it's the same keybindings as exist in Firefox for the same purpose. Could you please try those keystrokes instead? Thanks and sorry for the confusion. By the way, if, when using the keybindings I meant to say in the first place, you find that table navigation still fails, please attach a sample table to this bug because all my tests thus far have proven successful.
Yes, the alt-shift key combinations do the trick. Love the extra notification of spanning cells. I hadn't realized before that this document had spanned cells over the date headers. Excellent work! Also, I'm glad the key combination is alt-shift because that way, table navigation will be more consistent across different applications. I would have probably brought this up had shift not been included. That problem with the strait alt-arrow keys is still an issue but I don't think it is related to this bug so maybe I'll file something separate for that. I think that other symptom may be pretty old. So I look forward to the later parts to this enhancement; this is an excellent start!
Created attachment 136577 [details] [review] part 2: Add preferences Here's part 2, along with a new regression test for table structural navigation in Writer. Already pylinted and regression tested. Will, please review. Thanks!
Looking at part 3, we should decide what we want to do about formatting strings in structural navigation. structural_navigation.py's _presentObject method speaks header information (as appropriate and as desired, based on a user-configurable setting) and then calls the speech generator for the object. This works for Gecko. In the case of the dynamic row and column headers, the soffice speech generator knows how to obtain them and does so. As a result, if they are set, they will be spoken twice if the user has opted to have headings spoken and once if the user has disabled the speaking of headings. Formatting strings would (I believe) nicely address this issue. But formatting strings may not apply nicely/cleanly throughout all of structural navigation. Will suggestions? To me the choices seem to be: 1. Figure out formatting strings for structural navigation and then implement part 3 of this RFE. 2. Create a hack in the meantime which we'd remove upon figuring out formatting strings. 3. Remove the setting which allows the user to configure the speaking of headings in OOo Writer tables when using structural navigation. In other words, if you wanted to hear the dynamic headings in your Writer table when using structural navigation, set the headings first; if you don't, don't set them first or clear them. :-)
(In reply to comment #11) > Created an attachment (id=136577) [edit] > part 2: Add preferences > > Here's part 2, along with a new regression test for table structural navigation > in Writer. Already pylinted and regression tested. > > Will, please review. Thanks! You're a bit pickier about GUI stuff than I am, so I say I trust what you've done and say check it in to master if you're comfortable with it.
(In reply to comment #13) > You're a bit pickier about GUI stuff than I am, so I say I trust what you've > done and say check it in to master if you're comfortable with it. > Thanks! One question, however, regarding what I asked in comment #12: At the time I did part 2, I didn't realize that implementing part 3 would potentially be more involved than I'd originally thought. Therefore, I included a checkbox for the setting for speaking cell headers when using structural navigation in a Writer table. If we're about to deal with structural navigation formatting strings OR if you think I should hack around the problem I raised in comment #12, then I think we should check in my patch for part 2 as-is and then make that setting actually functional. On the other hand, if we are not about to deal with structural navigation formatting strings and I should not hack around the problem I raised in comment #12, then I think I should remove the non-functional checkbox from my patch for part 2 and worry about adding it back later.
In chatting via IM with Will about my question, he said that I should do what I thought was right. In looking at the odds (two out of the three options leading to the setting working as expected), I decided to leave the patch as-is and commit it to master. If it turns out I guessed incorrectly, I can always go back and remove it from the gui.
I noticed while trying this out recently that the header cells semed to speak and rather liked the idea. I didn't realize that that was happening "automatically" without special option. If I were to rank these in order of preference, I would say, #3 first since the implementation of the option could cause double speaking of the headers. If the option is desired, then I would suggest #1. The idea of "Hacking" to create a feature just gives a bad taste in my mouth. But then again, I'm not a developer of Orca yet so this is just my humble opinion.
Created attachment 137030 [details] [review] remainder of the work for this bug This implements the proper identification of headers by the structural navigation code and causes them to be presented based on the user's setting. (i.e. this change should make the table navigation user experience consistent between Gecko and OOo Writer.) Speaking of which.... This change takes advantage of the structural navigation code's ability to identify and present multiple headers when multiple headers apply to a single cell that spans more than one row and/or column. Pylinted. I'll run the regression tests now, but based on the changes I do not anticipate any regressions. Will, please review. Thanks!
Created attachment 137038 [details] [review] same patch with updated regression test All the tests passed. There are two differences: 1. This patch causes us to not double-braille something we were double brailling. That is a good thing. 2. In addition, in that same regression test, we apparently weren't closing our quotes, whereas now we are. I hadn't noticed that before (obviously). I assume this change is the result of one of the other recent checkins. Regardless, closing quotes that should be closed is a good thing. :-) So this patch is the same code-wize as the last version; it just has an updated regression test. Therefore, I think this patch is good.
(In reply to comment #18) > Created an attachment (id=137038) [edit] > same patch with updated regression test Looks great. I say commit. :-)
Yea! Thanks. :-) Updating the target to 2.27.4 since that is when the last of the work on this RFE went into master. Closing as FIXED.