Description: The design of "Automatically record the last 5 edit positions": ◎, the outer frame line color → "white. 』 ◎, fill the color → "black". ◎, digital color → "white". Note: 1. The "number" will be displayed only if there is a "record" in the location. 2. When the left mouse button is pressed, the button “Automatically record the last 5 edit positions” will be returned to the last edited position. 3. In the "Toolbar", add the "Automatically record the last 5 edit positions" button. When the button is pressed, "Automatically record the last 5 edit positions" will appear. Writer, Calc, Impress, Math, Draw, Base, all use this design. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 149681 [details] Automatically record the last 5 edit positions
Before implementing this as a GUI as here, the framework to expand the present single "Restore Edit View", reached with Shift-F5, to multiple locations would need to be considered--bug 92821 Otherwise in Writer the Navigation toolbar already provides exactly this function graphically while setting a "Reminder", or adding any other objects to canvas, from the Navigator dialog. Beleive that framework could be expanded, the "Reminder" objects being auto-generated--but a question then is how to handle it between sessions? 1. Record to user's LibreOffice XCU profile, in the document history 2. Record into the ODF, making it portable, as is done for the single "Edit View" now supported by Shift-F5 when the user bIsOwnDocument is True. Does this need to be portable? Probably not... Design of the widget could be as suggested, clickable buttons, or a keyboard driven movement (why not the Shift-F5), or use the neglected Navigation toolbar.
(In reply to V Stuart Foote from comment #2) 1. This is the most convenient design. As long as one hand presses the mouse, it is completed. ◎, "Shift + F5" requires 2 hands to complete, trouble. ◎, many people do not know the function of "Shift + F5", so "Shift + F5" is useless. 2, there are 5 buttons, you can directly reach the target ◎ If the design is such that there is only one button, the "circulation" will occur, which will be difficult to use and troublesome. 3. Consistency.
Too many UI elements clutter the view (and actually you don't want to go back to a specific point in history such as 1,2,3... but one step after another). I'd suggest to keep the history discussion at bug 92821 and think about a better usage of the Navigation toolbar (the use case was never clear to me and the back/forth controls could be used in future for the edit history rather than the "Navigator history"). *** This bug has been marked as a duplicate of bug 92821 ***