Created attachment 166744 [details] Navigator Problem Navigator problem. See .pdf attached
Jim, you are an expert in the Navigator, what do you think? James, for future don't write about your problem or your thinks in PDF in attach, write on site directly and attach only images. thanks
Hi James, I've copied your post from the Navigator Problem pdf attachment here to make it easier to discuss. >I am running LibreOffice:Version: 7.0.2.2 (x64)Build ID: >8349ace3c3162073abd90d81fd06dcfb6b36b994CPU threads: 4; OS: Windows 10.0 >Build 19041; UI render:Skia/Vulkan; VCL: winLocale: en-US (en_US); >UI: en-USCalc: threaded >please see images in the 'Navigator Problem' attachment >This is the LibreOffice Navigator "dialog". It is what you see if you press F5. >Note, first of all, there is no indication of where the focus lies... because, >in fact, the dialog does not have the focus, and the only way to bring the >focus to it is with a mouse click! >(This pretty much guarantees that the dialog is unavailable to the macro >recorder.) >Even if you do give the dialog the focus using the mouse, some of its contents >cannot be reached without another mouse click. For instance, I am interested in >the two large carets in the top row of the dialog": >But no number of tabs or shift-tabs will bring the focus to either one of >them. For me, repeated F6 key presses eventually change focus to the Navigator window 'Navigate By' drop down control. From there, tab, shift tab, and arrow keys can be used to navigate the Navigator. I confirm there is a bug with the new toolbox layout that does not allow 'Next' and 'Previous' 'Navigate By' controls to be reached using keyboard navigation. ---- separate topic --- >These carets have tool tips that identify them (incorrectly) as "Previous Page" >and "Next Page", but, in fact, they work differently than the PgUp and PgDn >keys because these carets put the top of the the target page at the top of the >viewport, whereas PgUp and PgDn bring the top of the target page in to the >viewport at a position one "page height" away from the current position of the >insertion point. Just to be clear about this, the carets in the navigator >dialog work much like turning the page of a book, whereas the PgUp and PgDn >keys scroll the view port up or down. I much prefer the former process, and so >I would like to attach the PgUp and PgDn keys to the actions of the top row >carets in the Navigator dialog. Unfortunately, the "Actions" window of the >"Customize" dialog does not list the book page turn action performed by the >carets. It does list "previous page" and "next page" but these actions perform >the scrolling version of the action in question.It does list "to begin of >previous page" and "to begin of next page" but these, too, perform the >scrolling action. As a result I cannot not get the page turning action I prefer >without the use of the mouse.[I raised this problem some time ago and I have >follow a long line of emails that seemed to indicate a solution was on the way. >Alas... not yet.] There was a patch done for this request you made in bug 101211. The user commands for these are 'To Next Page' (.uno:GoToNextPage) and 'To Previous Page' (.uno:GoToPrevPage). They can be assigned to PgDn and PgUp keys using Menu > Tools > Customize > Keyboard HTH :-)
Here is a patch that makes keyboard navigation of the first row of controls in the Writer Navigator possible. https://gerrit.libreoffice.org/c/core/+/105574
In light of the (presumably coming) new patch: Is there something that should or could be added to the help page for Navigator: https://help.libreoffice.org/7.1/en-US/text/swriter/01/02110000.html
(In reply to sdc.blanco from comment #4) > In light of the (presumably coming) new patch: > Is there something that should or could be added to the help page for > Navigator: > https://help.libreoffice.org/7.1/en-US/text/swriter/01/02110000.html Maybe. This patch helps to provide keyboard navigation of the Navigator as specified in the guidelines: https://design.blog.documentfoundation.org/2017/02/16/guidelines-for-keyboard-navigation-in-the-sidebar/
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b80c2745c50d064ad9e673cf8a5b73aaf0aa1778 tdf#137777 Writer: fix keyboard navigation of Navigator It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #6) > Jim Raykowski committed a patch related to this issue. > tdf#137777 Writer: fix keyboard navigation of Navigator > Affected users are encouraged to test the fix and report feedback. Maybe still a kink? IIUC, F6 can be used to shift focus to Navigator, then (Shift) Tab and/or cursor keys can be used to navigate through the Navigator panel, where the patch is supposed to allow the focus to shift through the "top line" of the panel. Problem with (Shift) Tab: skips one of the previous/next buttons. Two different cases. 1. Start in "Navigate by", press Tab (repeatedly). Actual sequence: "Previous", "Go to Page", (next line of Navigator panel) Expected (?) sequence: "Previous", "Next", "Go to Page", (next line of Navigator panel) That is, it skips "Next" 2. Start in "second row" (e.g, "Content Navigation View" icon), press Shift+Tab (repeatedly) Actual sequence: "Go to Page", "Next", "Navigate By" Expected (?) sequence: "Go to Page", "Next", "Previous", "Navigate By" That is, it skips "Previous" with Shift+Tab. Additional observation about Cursor keys If focus is on "Next" or Previous" (in top panel line), then BOTH right/left cursor arrows serve to toggle between Next and Previous, but cannot come further. (maybe that was intended?) (no effect with Up/Down) If focus is in "Navigate by" or "Go to Page", then left/right cursor keys do not cycle further (i.e., focus remains in boxes) (Just giving feedback, have no opinion about how it should be. Does not matter to me personally, but as a first reaction, the current behavior could probably be improved. (-: )
Comment 7 was tested with: Version: 7.1.0.0.alpha1+ (x64) Build ID: ccd0e5f445d4a7d0e7aca6c23c02c61bf14510b2 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
(In reply to sdc.blanco from comment #7) > (In reply to Commit Notification from comment #6) > > Jim Raykowski committed a patch related to this issue. > > tdf#137777 Writer: fix keyboard navigation of Navigator > > Affected users are encouraged to test the fix and report feedback. > > Problem with (Shift) Tab: skips one of the previous/next buttons. Two > different cases. The previous/next buttons are grouped controls so left and right arrows are used to navigate to them after reached by tab navigation. It may be better not to group these so the entire first line is tab only navigation?
(In reply to Jim Raykowski from comment #9) > The previous/next buttons are grouped controls so left and right arrows are > used to navigate to them after reached by tab navigation. > > It may be better not to group these so the entire first line is tab only > navigation? Probably James has to answer. I just naively assumed that the intention was to use Tab to navigate, because he wrote: > I am interested in the two large carets in the top row of the dialog": > But no number of tabs or shift-tabs will bring the focus to either one > of them. With "Tab" for everything, then one finger sits on Tab to navigate and the other on Enter (to use the carets to navigate up and down). (and it is not so hard to move the "Enter" finger to shift). But your query has inspired additional considerations (from naive user, experimenting without manual, perspective) and a counterproposal. 1. OTOH -- maybe I expected Tab to navigate the top row, because the left-right arrows could not "escape" from the combobox or spinbutton. 2. I can see that left/right arrow works to navigate the next two rows, so why wouldn't I expect that to work on the first row as well? 3. And if Tab were used to navigate in the first row, then why not the other rows? So -- a counter proposal -- for the sake of consistency and ease of understanding: How about "Tab" to move from row to row and then left-right arrows within a row? IMHO this works pretty well. As User, you understand that (shift) Tab allows you to move from each of the 5 major "sections" (?) of the Navigator (i.e., top row, middle row, bottom row, Content View, Document). And I can see that it already cycles around. And within (what I have called a section), then arrows are used to navigate. For top row, up/down already work in combo and spin button, but left-right does not. For middle and bottom row, left-right works fine (up/down works for drop-down) For content view -- all arrows work for navigating up/down, and opening/closing. In short, would be a consistent (understandable) principle (and easy to document (-: "Tab between sections, arrows within sections" ) and most of it already works in the existing interface. I think the only changes needed for this counter-proposal are: a. allow left/right arrows to navigate on the first row, b. only allow Tab to set focus on the first row (tried to see how this fits with the Design document on keyboard navigation, but this case did not seem to fit - or I did not know how to interpret). (but I am not trying to sell anything here -- just giving a naive user perspective.)
(In reply to sdc.blanco from comment #10) > With "Tab" for everything, then one finger sits on Tab to navigate and the > other on Enter (to use the carets to navigate up and down). (and it is not > so hard to move the "Enter" finger to shift). > > But your query has inspired additional considerations (from naive user, > experimenting without manual, perspective) and a counterproposal. > > 1. OTOH -- maybe I expected Tab to navigate the top row, because the > left-right arrows could not "escape" from the combobox or spinbutton. > > 2. I can see that left/right arrow works to navigate the next two rows, so > why wouldn't I expect that to work on the first row as well? > > 3. And if Tab were used to navigate in the first row, then why not the other > rows? > > So -- a counter proposal -- for the sake of consistency and ease of > understanding: > > How about "Tab" to move from row to row and then left-right arrows within a > row? > This is how things were but as pointed out in 1. left-right arrows can't be used to move out of the combobox or spinbutton. Hence the reason for the patch. It seems consistent with keyboard navigation of other panels with combobox and spinbuttons, e.g. Style, Character, and Paragraph panels in the Properties deck.
A polite ping to Jim Raykowski: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
(In reply to Xisco Faulí from comment #12) > A polite ping to Jim Raykowski: > Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? > Otherwise, Could you please explain what's missing? > Thanks Closing