In the navigator dialog there are two actions (represented by: < and > and with tooltips "Previous Page" and "Next Page"). When I click on one of these, it puts the top of the next or previous page at the top of the view port and that's exactly what I think Next Page and Previous Page should do. However, this is NOT what I get when I press PgDn or PgUp on my standard windows keyboard. Pressing either of those keys scrolls the visible text (up or down depending on which key you pressed) for a distance roughly equal to the height of the viewport and it moves the insertion point. "OK, I said" (when I discovered this problem some years ago", "I'll customize my keyboard to do what I want done then I press PgUp or PgDn. I find, in the list of functions I can assign the PgUp and PgDn keys two sets: Next Page and Previous Page and To Begin of Next Page and To Begin of Previous Page. The first pair does the scrolling action described above. The second pair moves the insertion point to the first character of the first line of the next or previous page, but it does not put that line at the top of the view port. The only way to achieve that (and as I said before, that is what I want to achieve) is to use the buttons in the tiny Navigator dialog. So I conclude that the action those buttons perform cannot be assigned to the PgUp or PgDn keys on a standard keyboard. Why not? Why won't you let me do what I want to do here? Plainly the code for the actions in question is already written and included in the program for a very long time. It would be a trivial thing to add the actions in question to the "Functions" list in the customize keyboard dialog, but I raised this question for the first time perhaps five or six years ago and nothing has ever come of it. Why can't we get this fixed. Thanks.
Here is a report about the default page down/up behavior: bug 81829 Let's ask the design team about this.
The number of lines to scroll on page up/down is defined by the operating system. And it also depends on many factors how much lines to scroll for the next page, so WONTFIX in this regards. What you can do is to configure your shortcuts (tools > customize) and assign page up/down to different functions. For instance 'to begin of next/previous page' at the Navigate category.
You really didn't pay attention to my original description of this problem. The "actions" I want to assign to pgup and pgdn are already implemented in Writer. They are available in the navigator "page navigation: dialog and they do exactly what I need done. The problem is that they are not listed among "functions" available for key assignments in the customize dialog, and so I am forced to write macros that do the job and assign them to pgup and pgdn. It's not an urgent problem, but it would be a trivial problem to fix. All that is required is to find the name of the pgup pgdn functions in the navigator "page navigation" dialog and add those function names to the list in the customize dialog. Blowing smoke on this request (nonsense about the OS limiting Writer's ability to scroll the viewport) is the sort of thing we used to see from Microsoft at its worst. LibreOffice should be better than that.
What the OP is reporting is that the Navigator's Previous Page and Next Page buttons are not available for keyboard shortcut binding.
So these two uno commands (.uno:GoToStartOfNextPage, .uno:GoToStartOfPrevPage) do not set the view to the top of the pages when they are jumped to similar to how the view changes in the navigator.
Can we get the commands from the navigator added to the customize dialog? Nobody has reported on why they aren't there already or whether this is feasible.
Created attachment 143949 [details] Illustration of Next/Prev page issue in Book View
I would like to add some emphasis to this issue, which does really hurt productivity when writing longer manuscripts using a typical PC/Laptop landscape display that allows display of two pages simultaneously in "Book View". Using the Next/Previous Page buttons in the Navigator panel I get a readable view with a correctly positioned page. But since these commands are NOT available to put on a shortcut key I constantly need to grab the mouse and go click them. The Next/Previous Page commands that ARE available for shortcuts are different, and gives me an unreadable view that I need to adjust using the scrollbar in order to be able to read the text. This is really painful, especially when editing or proofreading longer books.
This is really the most elementary behavior of the pgup pgdn keys, and Writer does it wrong. If you are in view whole page mode, pgup and pgdn should move to the prev/next page, not by some random amount that perhaps depends on the window size, or maybe the current distance to the planet venus.
I think I've found a hint as to why the navigator functions are not available in the customize menu. I've never used the navigator much, but playing with it today I discovered that the left and right arrow buttons are not, in fact, page buttons, but step through various elements of the page depending on the select made by clicking on the compass button (this whole system has several usability problems). For example, if you click the compass, then the table icon, the navigator arrow buttons will change to stepping through tables. The tooltips also change to reflect this. Bizarrely, the corresponding buttons within the compass menu are up and down arrows rather than left and right. This likely explains why there are no commands are not available in the customize menu. How this is all coded should also provide the answer as to whether said functionality could be added to the customize menu. It would be nice if someone who is familiar with the code could comment.
To summarize, here are the three sets of commands/functions mentioned so far, as I understand them. 1. "Next Page" and "Previous Page" commands -- these provide the default functionality of the PageDown and PageUp keys, and are bound as such in the customize dialog. The names are misleading, since they do not skip pages, but instead move the cursor some distance depending on the zoom and page content. 2. "To Begin of Next Page" and "To Begin of Previous Page" commands -- this is another pair that move the cursor, also available in the customize menu. These do set the cursor to the top of the page, but don't align the view port. 3. The "Next X" and "Previous X" buttons in the navigator -- when set to step through pages, these do align the view port, but not the cursor. They are specific to the navigator and are not available in the customize dialog for keybinding.
Created attachment 159258 [details] video demo of physical page up and down uno commands Hi Kenneth, I've hacked together a couple of uno commands to do page up and page down like the Navigate By control when the Page element is selected. These commands move the cursor to the start of the page unlike the Navigate By control which does not. Attached is a video demonstration. Let me know if I'm on the right track.
NEEDINFO is wrong status, reverting
(In reply to Jim Raykowski from comment #12) > ... > I've hacked together a couple of uno commands to do page up and page down > like the Navigate By control when the Page element is selected. These > commands move the cursor to the start of the page unlike the Navigate By > control which does not. Attached is a video demonstration. Let me know if > I'm on the right track. @Jim, looks good. But not sure the labeling as next/previous "physical" page is the best description.
@Jim I think you have it! Regarding naming, I would like to propose some new names, at least as a starting point for discussion. 1. Next/Previous Page -> "Page Up/Down", since they implement the default behavior of the PageUp and PageDown keys. I can't think of good names that are actually descriptive of what they do ("Scroll Up/Down" is sort of okay), but the current name is unacceptable. 2. To Begin of Next/Previous Page -> keep the same for now, since there are other commands with parallel names (which presumably behave similarly) 3. The new functions -> Option (a) -- "Next/Previous Page" -- fairly obvious for people looking for this functionality, and reflects the fact that there is no begin/end distinction (it always aligns to the top), but not clearly distinguished from (2) Option (b) -- "Next/Previous Page (Align Top)" -- wordy, but descriptive enough to distinguish it clearly from (2). Also leaves open the option to include parallel functions that align the bottom of the page (which may or may not be useful).
The term "physical" is used in the code for this kind of view movement [1]. .uno:PageUp and .uno:PageDown are already in use. Maybe .uno:GoToStartOfNextPageAlignTop .uno:ScrollToStartOfPrevPageAlignTop as suggested by Kenneth in Option (b)? [1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/viewport.cxx?r=4407a035#589
Here is a link to a patch sent to logerrit that implements these uno commands: https://gerrit.libreoffice.org/c/core/+/91605
Not a fan of too many UNO commands. It clutters at least the customization dialog. More relevant it makes a lot of trouble when it comes to removal - always a potential regression. So question is: Can't we make the existing command working like the "physical"? And about terminology, "physical" is not clear to the user. No need to play with the label when we keep what we have (with improvements).
(In reply to Heiko Tietze from comment #18) > Not a fan of too many UNO commands... The issue we run into is that PgUp (.uno:PageUp) / PgDown (.uno:PageDown) are scrolling commands useful for adjusting the "view port" of the VCL canvas as a scrolling increment--controlled by os/DE--and integral in selection actions. As scroll controls, they do not reposition the "edit cursor", nor should they. Nor do they work against page objects--just a view of the VCL canvas. What users are asking is the ability to position by document page increment. Key being the repositioning of the edit cursor and the view port (as needed) on the current VCL canvas. Our UI for page movement has been lacking compared to navigating other objects. We provide for "edit cursor" movement with UNO control by logical word, sentence, line, paragraph, frame, section. For example <Ctrl>+<Up> (.uno:GoToPrevPara) / <Ctrl>+<Down> (.uno:GoToNextPara), or the <Ctrl>+<Home> (.uno:GoToStartOfDoc) / <Ctrl>+<End> (.uno:GoToEndOfDoc). There has been no effective way to reposition to a previous page or next page object. Providing it requires a new UNO command for each for inclusion in the UI as Keyboard or Toolbar button actions. Legacy, and common, <PgUp> (uno.PageUp)/<PgDown> (uno.PageDown) are used for scrolling the view of our VCL canvas and making interactive selections, we can't change that--too much push back. On the other hand, <Ctrl>+<PgUp> (.uno:JumpToHeader) / <Ctrl>+<PgDown> (.uno:JumpToFooter) have been used to reposition the "edit cursor" into the nearest Header or Footer if present--or to top or bottom of page if not. And that usage could be shifted without major UX complaints. My suggestion would be: 1. retain the <PgUp> (.uno:PageUp) / <PgDown> (uno.PageDown) scroll, way to much disruption/grief from users to "hijack" an os/DE staple 2. use Jim's new UNO controls for the <Ctr>+<PgUp>, <Ctrl>+<PgDown> but rename them to "To Previous Page", "To Next Page" with better UNO names 3. shift the To Header / To Footer jump movements to be the <Ctrl>+<Shift> actions
(In reply to V Stuart Foote from comment #19) > > There has been no effective way to reposition to a previous page or next > page object. Providing it requires a new UNO command for each for inclusion > in the UI as Keyboard or Toolbar button actions. > Oops, should have mentioned outside of Navigator/Quick Find 'Page' mode. These new UNO controls bring capability to Keyboard and Toolbar customization.
@V Stuart Foote Your proposed keybindings sound good to me. Regarding names, I should clarify that I also find the "physical" moniker to be no good on the user side. I have some questions about UNO commands. 1. What is the UNO command for the "Next/Previous Page" commands? Are they the PageUpCursor and PageDownCursor functions in the code Jim linked? 2. In the customize dialog, is there any difference between commands labeled "Go to next X" vs simply "To next X"? Also, the names I proposed were all labels for the UI. So, if only the "Page(Up/Down)Cursor" commands are made available to the, my proposed name would (presumably) result in providing the C++/UNO "Page(Up/Down)Cursor" command as "Page Up" in the UI.
(In reply to Kenneth Hanson from comment #21) > @V Stuart Foote > > Your proposed keybindings sound good to me. > I agree, so? .uno:GoToPrevPage 'To Previous Page' .uno:GoToNextPage 'To Next Page' > > I have some questions about UNO commands. > > 1. What is the UNO command for the "Next/Previous Page" commands? Are they > the PageUpCursor and PageDownCursor functions in the code Jim linked? > 'To Begining of Next Page' is .uno:GotoStartOfNextPage 'To Begining of Previous Page' is .uno:GotoStartOfPrevPage The linked functions in the code are what the Navigate By control uses for Page element navigation. They aren't used by any UNO command AFAIK. > 2. In the customize dialog, is there any difference between commands labeled > "Go to next X" vs simply "To next X"? > I think that is just an inconsistent naming difference. > Also, the names I proposed were all labels for the UI. So, if only the > "Page(Up/Down)Cursor" commands are made available to the, my proposed name > would (presumably) result in providing the C++/UNO "Page(Up/Down)Cursor" > command as "Page Up" in the UI. Sorry, you lost me. Regardless of what the UNO command name is you will be able to assign whatever shortcut key to it you wish.
(In reply to Jim Raykowski from comment #22) > ... > I agree, so? > > .uno:GoToPrevPage 'To Previous Page' > .uno:GoToNextPage 'To Next Page' > Perfect! And let's keep the current .uno:PageUp, .uno:PageDown in place as <PgUp>/<PgDown> for their scrolling function. So the new 'To Previous/Next Pagw would get <Ctrl>+<PgUP>/<PgDown> keyboard binding, while moving the less common .uno:JumpToHeader, .uno:JumpToFooter to the <Shift><Ctrl>+<PgUp>/<PgDown> bindings? A tad more work, here and for documentation, but reasonable way to finish this out. Thanks Jim.
Remaining decision is if it would make since to swap in these new .uno:GoToPrevPage/NextPage to the listbox for the QuickFind and Navigator mode changes? Replacing the GoToStartOfPreviousPage/NextPage and align actions--so edit cursor would change with the viewport.
(In reply to Jim Raykowski from comment #22) > > Also, the names I proposed were all labels for the UI. So, if only the > > "Page(Up/Down)Cursor" commands are made available to the, my proposed name > > would (presumably) result in providing the C++/UNO "Page(Up/Down)Cursor" > > command as "Page Up" in the UI. > > Sorry, you lost me. Regardless of what the UNO command name is you will be > able to assign whatever shortcut key to it you wish. Let me try again, taking into account what you two have said recently. I don't know what the UNO and C++ names are for anything (though I am picking them up gradually here), just the names in the customize dialog and in the rest of the UI. This makes things difficult. 1. You two refer to .uno:PageUp/PageDown. I think that these are the commands that are currently labeled "Next/Previous Page" in the customize dialog. If so, the names of the UNO commands are fine, but the names in the customize dialog need to be changed. They are misleading as is, and will only get worse when the new commands are added. 2. I now understand that 'To Begin of Next/Previous Page' is .uno:GotoStartOf(Next/Prev)Page. Okay, good. 3. You proposed .uno:GoTo(Prev/Next)Page / 'To Previous/Next Page' for the new functions. I'm happy with this if you guys are. But the functions in #1 MUST be renamed.
(In reply to V Stuart Foote from comment #24) I think this needs further discussion, probably a separate bug. Currently, double clicking named objects in the navigator moves the cursor. Or at least, it does for headings and tables. I haven't tested everything. But page navigation currently works differently. No matter what you pick in the compass menu, the previous/next buttons do not move the cursor. So we would have to consider the cursor should always move, never move (as it is now), or whether it should vary for each object type.
(In reply to Kenneth Hanson from comment #25) > (In reply to Jim Raykowski from comment #22) > > > Also, the names I proposed were all labels for the UI. So, if only the > > > "Page(Up/Down)Cursor" commands are made available to the, my proposed name > > > would (presumably) result in providing the C++/UNO "Page(Up/Down)Cursor" > > > command as "Page Up" in the UI. > > > > Sorry, you lost me. Regardless of what the UNO command name is you will be > > able to assign whatever shortcut key to it you wish. > > Let me try again, taking into account what you two have said recently. > > I don't know what the UNO and C++ names are for anything (though I am > picking them up gradually here), just the names in the customize dialog and > in the rest of the UI. This makes things difficult. > Easy to search for either label (as shown in UI) or the command name: https://opengrok.libreoffice.org/ Most of these sorts of things are in the 'core' project. > 1. You two refer to .uno:PageUp/PageDown. I think that these are the > commands that are currently labeled "Next/Previous Page" in the customize > dialog. If so, the names of the UNO commands are fine, but the names in the > customize dialog need to be changed. They are misleading as is, and will > only get worse when the new commands are added. > Yes, but they are "scrolling" commands, and reposition the document canvas by some os/DE defined value, *complementing* the VCL canvas movement commands (all defined as UNO Actions as well) linked to single keyboard keys (Down, Up, Left, Right, Home, End, PgDown, PgUp)--essential to movement behavior typical of all text editors. The related goto/jump UNO commands, affecting viewport, are with <Ctrl>--KEY_MOD1--assignments by default. And why, moving the Jump to Header/Footer assignments to <Ctrl><Shift>--KEY_MOD1 + KEY_MOD2 is needed to free up for use for the new GoToPreviousPage/GoToNextPage. > 2. I now understand that 'To Begin of Next/Previous Page' is > .uno:GotoStartOf(Next/Prev)Page. Okay, good. > That was the legacy Navigator control, it got cleaned up a few years back to fix alignment to the top of the page, but it never relocated the Edit Cursor. Not sure if it is still needed once the new controls are put in.
(In reply to V Stuart Foote from comment #27) > Easy to search for either label (as shown in UI) or the command name: > > https://opengrok.libreoffice.org/ > > Most of these sorts of things are in the 'core' project. Thanks. > > 1. You two refer to .uno:PageUp/PageDown. ... > > Yes, but they are "scrolling" commands, ... I think I understand what you said. I just wanted to confirm the naming issue. > > 2. I now understand that 'To Begin of Next/Previous Page' is > > .uno:GotoStartOf(Next/Prev)Page. Okay, good. > > > > That was the legacy Navigator control, it got cleaned up a few years back to > fix alignment to the top of the page, but it never relocated the Edit > Cursor. Not sure if it is still needed once the new controls are put in. I can imagine cases where you might not want to align the top of the page, but rather get the top or bottom of the page in view with surrounding context. So they might be worth keeping.
(In reply to Kenneth Hanson from comment #25) > I don't know what the UNO and C++ names are for anything (though I am > picking them up gradually here), just the names in the customize dialog and > in the rest of the UI. This makes things difficult. > Version 7, Customize dialog, Available Commands list box, has a tooltip that shows the UNO command. The Description box shows the UNO command for the selected command in the list box.
(In reply to Jim Raykowski from comment #22) > .uno:GoToPrevPage 'To Previous Page' > .uno:GoToNextPage 'To Next Page' > 'To Begining of Next Page' is .uno:GotoStartOfNextPage > 'To Begining of Previous Page' is .uno:GotoStartOfPrevPage Remember we have tooltip that can be more verbose like "Move cursor to next/previous page" and "Scroll to beginning of the next/previous page". So a shorter string like "Previous/Next Page" and "Scroll page down/up" make sense.
(In reply to Heiko Tietze from comment #30) > (In reply to Jim Raykowski from comment #22) > Remember we have tooltip that can be more verbose like "Move cursor to > next/previous page" and "Scroll to beginning of the next/previous page". > So a shorter string like "Previous/Next Page" and "Scroll page down/up" make > sense. That's right, TooltipLabel can be used for this in WriterCommands.xcu[1] and, as an added bonus, the keyboard binding is automatically appended to the tip. Cool stuff! I am confused about the wording to use for the tip. For the patch, I will simply use 'To Previous/Next Page'. Accelerators.xcu[2] contains default keyboard bindings. I think changing the bindings should be done in a separate patch. [1] https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu?r=96def0ee [2] https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Accelerators.xcu?r=02cac3ee
(In reply to Jim Raykowski from comment #31) > ... > I am confused about the wording to use for the tip. For the patch, I will > simply use 'To Previous/Next Page'. +1 > > Accelerators.xcu[2] contains default keyboard bindings. I think changing the > bindings should be done in a separate patch. +1 And were you going to look at swapping them in for use as Navigator's page mode movements?
(In reply to V Stuart Foote from comment #32) > > And were you going to look at swapping them in for use as Navigator's page > mode movements? I will look at doing that, but think it should be done in a separate patch.
(In reply to Jim Raykowski from comment #33) > I will look at doing that, but think it should be done in a separate patch. +1
Some findings: When the view is scrolled to a page that does not have the cursor, 'Page Up/Down' (.uno:PageUp/Down) scroll the view and reposition the cursor relative to the current page in the view. 'To Beginning of Previous/Next Page' (.uno:GotoStartOfNext/PrevPage) scroll is done relative to the page with the cursor. E.g. Cursor is located on page 2 and view is scrolled to show page 10. 'To Beginning of Previous Page' scrolls view to page 1 versus 'Page Up' which either scrolls to page 10 or page 9 and positions cursor in one or the other. 'Navigate By Page' follows the Page Up/Down behavior of page scrolling relative to the view. The first approach for the new 'To Previous/Next Page' commands follow the same scroll behavior as 'To Begining of Previous/Next Page', scroll relative to page of cursor. The second approach (Patch Set 4) follows 'Page Up/Down' behavior, scroll relative to page in view.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/021f0b4a8c556561f5b0a5fe2ecc20209d548193 tdf#101211 Add goto prev and next page uno commands 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 #36) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": @Jim, I'll have to test when it rolls, but is cursor focus moving with the page repositioning? Or, are we now just scrolling in full page increments? Unclear from the comments in https://gerrit.libreoffice.org/c/core/+/91605 While the current pgDn/pgUp .uno commands scroll (leaving cursor focus behind); seems like doing so with full page movements is going to cause some annoyance at needing to mouse click into the page view to gain cursor focus. Also, what keyboard shortcut assignment adjustments to be made--the <Ctrl>+pgDn/<Ctrl>+pgUp used by toFooter/toHeader need to be moved to free them up for full page movements.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ea59cd05e84849c3fde514b7070081af4a052360 tdf#101211 follow-up: move cursor to start of next/prev pg UNO functions 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.
Created attachment 161598 [details] Demo of GoToNextPage and GoToPrevPage uno commands The follow up patch fixes the cursor not moving to the start of the next/previous page when multiple pages are visible. The behavior of these uno functions is to move the cursor to the start of the next/previous page. If the cursor is visible, the page number the cursor is on is used as the reference. If the cursor is not visible, the page number of the first visible page is used. Hopefully the video demo will clarify this.
(In reply to V Stuart Foote from comment #37) > Also, what keyboard shortcut assignment adjustments to be made--the > <Ctrl>+pgDn/<Ctrl>+pgUp used by toFooter/toHeader need to be moved to free > them up for full page movements. Maybe just leave up to user to assign?
(In reply to Jim Raykowski from comment #40) > (In reply to V Stuart Foote from comment #37) > > > Also, what keyboard shortcut assignment adjustments to be made--the > > <Ctrl>+pgDn/<Ctrl>+pgUp used by toFooter/toHeader need to be moved to free > > them up for full page movements. > > Maybe just leave up to user to assign? Well except for discoverability, and frequency of use. I'd think more users would move by page (and scroll) than would need keyboard jump into Footer or Header block. The Navigator will facilitate movement by page, but the pgDn/pgUp key assignments will be with the scroll movements (partial page now with cursor focus along). So then how to discover to move by full page by keyboard? Assigning new page movements to <Ctrl>+pgDn/pgUP would be logical complements to <Ctrl>+Home/End page movements, and the whole set of cursor/home/end movements. Retaining usage for the toFooter/toHeader just seems out of sequence to a good UX.
(In reply to V Stuart Foote from comment #41) > (In reply to Jim Raykowski from comment #40) > > Maybe just leave up to user to assign? > > Well except for discoverability, and frequency of use. A tip of the day could help advertise this. > I'd think more users would move by page (and scroll) than would need > keyboard jump into Footer or Header block. I agree. > So then how to discover to move by full page by keyboard? Tip of the day and help documentation 'Navigating and Selecting with Keyboard section'[1]. Looks like the Page Up and Page Down key help there needs some work. Maybe the help documentation gurus will help us with that :-) > Retaining usage for the toFooter/toHeader just seems out of sequence to a > good UX. [1] https://help.libreoffice.org/7.0/en-US/text/swriter/guide/text_nav_keyb.html
Keybinding question is on bug 105776. Guess we can resolve this ticket now.
*** Bug 65885 has been marked as a duplicate of this bug. ***
*** Bug 140448 has been marked as a duplicate of this bug. ***