In my opinion, the navigate back funtion is a little unintuitive to use, in the way that it behaves when the user has scrolled the view, so that the cursor is no longer visible. In this case, the navigate back function does not take the user back to the place where cursor is, but to the place where it was before. I think most people would first want to go back to the place where the cursor is currently and only in the case where the cursor is already in the view, then go where the cursor was previously. In summary, navigate back function should IMO: * Check if the cursor is visible * if cursor is not visible -> scroll to make cursor visible * if cursor is visible -> move where the cursor was previously I don't have c++ experience, but here are links to code sections I think might be relevant for implementing this. void SwNavigationMgr::goBack() https://docs.libreoffice.org/sw/html/navmgr_8cxx_source.html#l00094 Here are some places where one might want look for how to check if cursor is visible and to make it visible bool SwWrtShell::Left https://docs.libreoffice.org/sw/html/move_8cxx_source.html#l00110 // scroll Cursor to visible area https://docs.libreoffice.org/sw/html/crsrsh_8cxx_source.html#l02288 void SwCursorShell::MakeSelVisible() https://docs.libreoffice.org/sw/html/crsrsh_8cxx_source.html#l03392 PS. I also made this related Bug 169479 report, to add Alt+left shortcut to navigate back function.
The Sidebar Navigator navigate-by 'Recency' mode maintains a stack of multi-source cursor positions [1] or views within a current document. The 'Go Back' 'Go Forward' buttons of the Navigator are also presented in the reworked Navigation toolbar. The Stack of cursor positions/views by 'Recency' is distinct from the independent stack for each of type element that the Navigator tracks. The scope of the 'Recency' navigation are the actions across the entire Writer UI. Note that "scrolling" the document does not drop a 'Recency' event--nor should it. Though you could add it to the stack--simply mouse click (to reposition edit cursor), or drop a reminder, or add a bookmark [events as listed in 1]. IMHO it functions correctly, and as expected... => WF =-ref-= [1] enumerated https://bugs.documentfoundation.org/show_bug.cgi?id=115817#c43
Thank you for a very speedy response! I want to clarify that technically speaking this go back/forward future works as intended and I do not suggest any modifications to the back/forward stack management of this feature. I do understand that "scrolling" the document does not drop a 'Recency' event and I fully agree that it should not. Only thing I am suggesting is, that in order to make this functionality more intuitive and useful for a regular user, there should be a special handling for situations when a user has scrolled/moved the view so that the cursor is no longer visible. To handle this, the function go back should check if the cursor is in the view and if not, then scroll/move the view to make the cursor visible without any manipulation of the back/forward stack. Consider the following: 1. user scrolls to paragraph 20 and modifies/inputs some text 2. user scrolls to paragraph 40 and modifies/inputs some text 3. user scrolls to paragraph 60 to read some text and then wants to change the previously written text to paragraph 40 Under the current implementation, if the user now presses the back button, then the user is taken straight to paragraph 20, which I think this is not what most would expect in this situation. The previous paragraph the user was editing was paragraph 40 and most users would expect to go back there. Yes, the user could go back to the expected place (paragraph 40) by just clicking mouse somewhere and press the go back button after that. The problem is, that 99,99% of users would not know that. Also, why would you require the user to do that, if this could be handled automatically with a small change to the code. With my suggestion, the go back function would check that cursor is not in the view and the go anywhere where back/forward stack pointer points to, without changing the stack in any way. Now, if the user would press back button again, while the cursor is visible, the back function would goto paragraph 20 and update the stack as it allways has.
OK, Like cursor edit actions, the go-to reposition movements already push onto the stack so no issue there. But to support jump back after scroll movements, is there an efficient way to read current viewport and compare it against last position on the "recency" stack? A means to test, in-view OR out-of-view, the last scrolling position (the final viewport before a position call against the recency stack). @Jim, what do you think?
(In reply to V Stuart Foote from comment #3) > But to support jump back after scroll movements, is there an efficient way > to read current viewport and compare it against last position on the > "recency" stack? > > A means to test, in-view OR out-of-view, the last scrolling position (the > final viewport before a position call against the recency stack). Question, do we need to access the last position on the "recency" stack? The way I see this, the currently active cursor position must be the last position on the "recency" stack. If this assumption is true, then the question simply becomes: is the active cursor visible, and if not, make it visible.
(In reply to devseppala from comment #4) >... is the active cursor visible, and if not, make it visible. Yes, that would work also and could cut some overhead. IIUC it will depend on how the current edit cursor in-view, or not, can be determined. And as "locations" of the edit cursor are what are held on the 'Recency' stack--believe it remains in the mix.
What about when the Forward button is only active? Should pressing it return to the position of the cursor when it is scrolled out of the visible view?
Please ignore my previous comment. Here is a link to a patch that provides the requested enhancement: https://gerrit.libreoffice.org/c/core/+/194147
Thanks @Jim. While testing this implementation, did you find it to be more intuitive and an improvement over the old behaviour? Will there be a test build you would like have tested?
(In reply to devseppala from comment #8) > Thanks @Jim. While testing this implementation, did you find it to be more > intuitive and an improvement over the old behaviour? Will there be a test > build you would like have tested? I think it's an improvement over the old behavior. Possibly Forward navigation should also have the same behavior. Let's wait for input from UX before merging the patch. If approved then the merged patch can be tested by installing a nightly build: https://www.libreoffice.org/download/pre-releases If interested, here is a link to how to build LO from the current source so you can apply the patch and test now: https://www.libreoffice.org/about-us/source-code Once built the patch can be applied by: git fetch https://git.libreoffice.org/core refs/changes/47/194147/2 && git format-patch -1 --stdout FETCH_HEAD | git apply then: make sw and run: ./instdir/program/soffice
(In reply to Jim Raykowski from comment #7) > Please ignore my previous comment. > > Here is a link to a patch that provides the requested enhancement: > https://gerrit.libreoffice.org/c/core/+/194147 +1 this is the needed behavior. And, not clear how the .uno:NavigateForward would be needed. Seems like for a scroll in either direction that results in an out-of-view edit cursor that the .uno:NavigateBack returns from either direction? I'm still conflicted regards pre-assigning a shortcut (i.e. <Alt>+<Right>/<Left> to the UNO) of see also bug 169479.
I wouldn't enable the same functionality on the forward operation because I believe: 1. It could confuse people if back and forward functions can go to same place. 2. Intuitively, I think the current cursor position is in the past, hence go back. However, I see the problem highlighted in Jim's now obsolete comment. People could get accustomed to using the back button just to return to the active cursor position, but the back button can be disabled if "back to" stack is empty. In this situation, the user can't use this function to return the view to the active cursor position. This situation is only possible in the very beginning of the editing session, but in a continuing operation there is always something in the go back stack. To resolve this issue, would it be possible to newer to disable the back to button? If cursor is visible and back to stack is empty, then just do nothing or echo a warning sound.
@Stuart and @Jim, did you test does the new implementation work even if there is no active text cursor, but some other object is chosen? ie. 1. User selects Frame/Image so that the size adjustment squares show up 2. User scrolls the view so that the Frame/Image is not visible 3. User returns to the Frame/Image using the go back function I may try to do my own build over the weekend, but thought to ask if you already tested this.
(In reply to devseppala from comment #12) > @Stuart and @Jim, did you test does the new implementation work even if > there is no active text cursor, but some other object is chosen? > > ie. > 1. User selects Frame/Image so that the size adjustment squares show up > 2. User scrolls the view so that the Frame/Image is not visible > 3. User returns to the Frame/Image using the go back function > > I may try to do my own build over the weekend, but thought to ask if you > already tested this. Yes, I tested this case. For me, scroll back to the selected frame happens as expected.