Created attachment 158300 [details] Navigate document while remaining in Navigator Attached is a screen recorded demo. If this is useful I will submit patch for review.
I'm split as single click default action makes a pure selection impossible. For example, you cannot promote a chapter without jumping to it. Or rename a shape. OTOH, your video shows nicely that "single selection" in the document works respectively. One click on a different chapter and you get another item selected in the Navigator. I'm against an option. PS: Jim, please never create a template :-)
We discussed this topic in the design meeting. Provided the video showcases a switch from the current double click behavior to go to the heading or the object towards a single click we have concerns. + con: usually the default action (go-to) is done by double click + con: single click blocks context menu for not active object + keep the context menu could be done also by special handling of right button + con: breaks flow where you work in Headings-part, and select e.g. an image or work in a table + pro: weird situation when a different item is selected as the active position; wouldn't be an issue with single click + similar issue with styles & formatting where single click does not apply the style (bug 94427) + rather a different topic IMO (Cor) + pro: in document selection is a single click and changes the Navigator + with no clear need, let's not break the known behavior, present left and right (Cor) + tend to weight the pro higher (Heiko) + the other way round for me; will likely hate it (Cor) Jim, please comment if the assumption is wrong. Otherwise it's up to you to balance the pro and cons, keeping the ticket open.
(In reply to Heiko Tietze from comment #2) > We discussed this topic in the design meeting. Provided the video showcases > a switch from the current double click behavior to go to the heading or the > object towards a single click we have concerns. > > + con: usually the default action (go-to) is done by double click Double click or Enter key places focus (goes into) the document content. Single click scrolls document to selected navigation content view entry. > + con: single click blocks context menu for not active object Isn't that how it currently is? Right click on any item in the content tree and that item is selected and the associated context menu is shown. > + keep the context menu could be done also by special handling of right > button ? > + con: breaks flow where you work in Headings-part, and select e.g. an image > or work in a table Agree > > + pro: weird situation when a different item is selected as the active > position; wouldn't be an issue with single click True, what ever is selected in the Navigator will be scrolled to in the document > + similar issue with styles & formatting where single click does not apply > the style (bug 94427) > + rather a different topic IMO (Cor) I'm with Cor here > + pro: in document selection is a single click and changes the Navigator Outline position is tracked in the Navigator but that's a separate "enhancement" > + with no clear need, let's not break the known behavior, present left and > right (Cor) I am unfamiliar with the expression "present left and right". I don't have an opinion on the need. This is something I saw mentioned in a bug/enhancement report. I've been doing a few things in this area of the code so it wasn't much of a stretch to do this. > > + tend to weight the pro higher (Heiko) > + the other way round for me; will likely hate it (Cor) No opinion. > PS: Jim, please never create a template :-) TBH, I don't know how to create a template. I get the feeling, for the file used in the demo, it is a good thing that I don't. :-)
(In reply to Jim Raykowski from comment #3) > Double click or Enter key places focus (goes into) the document content. > Single click scrolls document to selected navigation content view entry. So the cursor remains where at the same position and the user has to move up/down to get back. I wonder if this not so common behavior would improve to something delightful when we go back per escape or another single click on the not active node. Point is that the highlighted node in the Navigator is not trustworthy anymore (like bug 94427). Would be good to have a special visualization like grey for items where the cursor is and blue for the selected node (and blue if both are the same). > > + con: single click blocks context menu for not active object > > Isn't that how it currently is? Right click on any item in the content tree > and that item is selected and the associated context menu is shown. Currently you don't scroll or jump to what you select. With the patch it's not possible to rename objects, for example, without scrolling to it.
Just as a point of reference, I'd like to compare the suggested functionality with the "document map"/"navigation" in Microsoft Word and the "document outline" in Google Docs. (I normally only use the LO Navigator for jumping between different headings, so I can't really comment on the usage for other use cases/objects e.g. Images, Tables, Frames, etc.) # Microsoft Word 2003 (because I happen to have it lying around): Note: - Document map = the left sidebar listing all of the headings and subheadings in the document - Main text = the big main area on the right containing all of the text in the document, where the caret is Observations: 1-1. If I move the caret in main text: The selected heading in the document map automatically updates to match the caret location. 1-2. If I single-click a heading in document map: That heading in document map gets selected. Keyboard focus remains in main text. Caret in main text jumps to that heading. 1-3. If I double-click a heading in document map: That heading in document map gets selected. Keyboard focus remains in main text. Caret in main text jumps to that heading. The expanded/collapsed status of the subtree under that heading in document map gets toggled. 1-4. If I click the little [+] or [-] to the left of a heading in document map: Keyboard focus remains in main text. Caret location in main text is unchanged. Selected heading in document map is unchanged. The expanded/collapsed status of the subtree under that heading in the document map gets toggled. 1-5. If I press "F6" while focused in main text: Keyboard focus moves to document map. Up and down arrow keys change selected heading in document map. Right arrow key expands subtrees. Left arrow key collapses subtrees. Caret location in main text remains unchanged throughout all this. If I hit "Enter", then keyboard focus returns to main text, and caret jumps to that location in the main text. Alternatively, if I hit "F6", focus returns to main text, selected heading in document map reverts to that of the current caret location, and caret location in main text is unchanged. 1-6. If I right-click a heading in document map: That heading in document map gets selected. A context menu appears containing the followng items: "Document Map" / "Expand", "Collapse" / "Show Heading 1", "Show Heading 2", ..., "Show Heading 9", "All". Keyboard focus moves to the right-click context menu. Caret location in main text is unchanged. As soon as I click one of those items (e.g. "Expand"), that action gets applied, and then the selected heading in document map reverts to that of the current caret location. Keyboard focus returns to the main text. Caret location in main text is unchanged. 1-7. If I right-click a heading in document map and then click somewhere in main text: Selected heading in document map reverts to current caret location. Caret location in main text is unchanged (even if you clicked a location in the text other than where the caret is). 1-8. If I right-click a heading in the document map and then hit "Esc" or click somewhere other than the main text (e.g. the title bar, the status bar, etc.): The right-clicked heading in document map is now selected, and keyboard focus moves to document map. Caret location in main text is unchanged. # LibreOffice Writer 6.3.5.2 (because I happen to have it lying around): (While in content navigation view.) 2-1. If I move the caret in main text: The selected heading in the navigator automatically updates to match the caret location (but there's a curious half-second delay). 2-2. If I single-click a heading in navigator: That heading in navigator gets selected. Keyboard focus moves to navigator. Caret location in main text is unchanged. 2-3. If I double-click a heading in navigator: That heading in navigator gets selected. Keyboard focus remains in main text. Caret in main text jumps to that heading. 2-4. If I click the little [+] or [-] to the left of a heading in navigator: Keyboard focus moves to navigator. The selected heading in navigator is unchanged. Caret location in main text is unchanged. The expanded/collapsed status of the clicked heading's subtree in navigator gets toggled. 2-5. If I press "F6" while focused in main text: Keyboard focus rotates from main text to the menu bar, then the first toolbar, then the second toolbar, then the first button in the navigator panel (the one with the compass icon). If I hit "Tab" here, it rotates keyboard focus from the navigator toolbar, then the central headings list, then the bottom document indicator (e.g. "Untitled 1 (active)"). If I stop in the central headings pane, I can use arrow keys to change the selected heading in navigator. Up and down arrow keys change the selected heading in the navigator. Right arrow key expands subtrees. Left arrow key collapses subtrees. Caret in main text remains unchanged throughout all this. If I hit "Enter", then keyboard focus returns to main text, and the caret jumps to that heading's location in the main text. Alternatively, if I hit "F6", then the keyboard focus moves away to the next toolbar, and then after a curious half-second delay, the selected heading in navigator reverts to the current caret location. Caret location in main text is unchanged. 2-6. If I right-click a heading in navigator: That heading in navigator gets selected. A context menu appears containing the following items: "Outline level >", "Drag Mode >", "Display >". That heading in navigator gets selected. Keyboard focus moves to the context menu. Caret location in main text is unchanged. After about a second or so, the selected heading in navigator reverts to what it was before, even though the context menu is still open. Keyboard focus is still in context menu. If I select one of the menu items, then the selected heading (i.e. the one from before right-clicking) remains highlighted (i.e. dark blue) but the heading that I right-clicked now has a dotted grey outline. If I use the arrow keys to navigate, the selected heading is the one immediately above/below the dotted grey outline, not the dark blue highlight. 2-7. If I right-click a heading in navigator, wait about a second or so, and then click somewhere in main text: Dark blue highlight on previous heading (i.e. NOT the right-clicked heading), grey outline on right-clicked heading. Keyboard focus moves to navigator. Caret location in main text is unchanged. 2-8. If I right-click a heading in navigator, wait about a second or so, and then hit "Esc" or click somewhere other than the main text (e.g. the title bar, the status bar, etc.): Keyboard focus moves to navigator. Both dark blue highlight and dotted grey outline are on the previous heading (i.e. NOT the right-clicked heading). # Google Docs, in Chrome: (Here, the left pane is called "document outline".) 3-1. If I move the caret in main text: Selected heading in document outline auto-updates. 3-2. If I single-click a heading in document outline: Heading in document outline gets selected. Keyboard focus remains in main text. Caret in main text jumps to that heading. 3-3. If I double-click a heading in document outline: Exactly the same as single-click. 3-4. No [+] or [-] collapsible controls in document outline. 3-5. If I press "F6": It rotates keyboard focus between the main Chrome content pane, the Chrome URL bar, and the Chrome tabs list. 3-6. If I press "Ctrl + F6": Nothing happens. 3-7. If I right-click a heading in document outline: A right-click context menu appears, but it's just the usual Chrome one ("Back", "Forward", "Reload", etc.) Keyboard focus moves to context menu. Pressing "Esc" or clicking in the main text returns keyboard focus to main text. # Word Online, in Chrome (because I don't have any recent versions of Word installed): (Here, the left pane is just called "navigation".) 4-1. If I move the caret in main text: Navigation pane selection doesn't change at all. Initially, no headings in navigation pane are selected. If I click one of the headings in navigation pane to select it and then move the caret elsewhere in the main text, the navigation pane selection doesn't update to match the caret location. 4-2. If I single-click a heading in navigation pane: That heading in navigation pane gets selected. Keyboard focus remains in main text. Caret in main text jumps to that heading. 4-3. If I double-click a heading in navigation pane: Exactly the same as single-click. 4-4. No [+] or [-] collapsible controls in navigation pane. 4-5. If I press "F6": It rotates focus between the main Chrome content pane, the Chrome URL bar, and the Chrome tabs list. But a helpful orange pop-up also appears, with the message "Press CTRL+F6 to move around Word. Press Alt Shift A for Accessibility Help." 4-6. If I press "Ctrl + F6": It rotates keyboard focus from the main text to the status bar, then the 3x3 square hamburger menu bar thing in the top left, then the menu bar, then the finally the search text field in the navigation pane. If I press "Tab" here, it rotates keyboard focus within the navigation pane, from the search text field, to the search button, then each individual heading. Arrow keys don't do anything here. If I press "Esc" here, it closes the navigation pane and returns keyboard focus to the main text. Alternatively, if I press "Enter" at one of the headings, it returns keyboard focus to main text, and jumps the caret in main text to that heading. 4-7. If I right-click a heading in navigation pane: That heading in navigation pane gets selected, but confusingly, the previously selected heading in navigation pane is also still selected (i.e. there are two selected headings now). No context menu appears. Keyboard focus remains in main text. Caret in main text is unchanged. As soon I try any key presses, they act on the main text as usual, but also the right-clicked selection in navigation pane vanishes.
And also, some anecdata with sample size n = 1: I mainly use Word, so note that my familiarity is biased in that direction. However, I have used LibreOffice for long stretches of time in various work environments. Anyway, this is my experience: 1. >95% of the time, I use the navigator to quickly jump between headings in a large document. So, single-click >>>>>>>>> double-click (for me, at least). It may not seem like much of a difference, but over the course of multiple clicks, the additional hassle of a double-click really becomes noticeable. 2. <5% of the time, I create a new heading and oops, I set it to the wrong level. For this, I assigned the keyboard shortcuts "Alt + Shift + Left" and "Alt + Shift + Right" to the commands "Decrease Level" and "Increase Level" respectively, and I use those to adjust the heading level. These are default shortcuts in Word, but not in LO (afiak). 3. <1% of the time, I want to reorder some headings. Click-and-drag in LO's navigator makes this really easy. In Word (my very obsolete version), I have to go to outline view, set the show outline level accordingly to hide the text, and then click and drag from there. If these are multiple sibling headings, I do them one by one. But normally it's just one parent heading + multiple child headings. I don't really use the navigator for anything else.
(In reply to Heiko Tietze from comment #2) > + con: breaks flow where you work in Headings-part, and select e.g. an image > or work in a table > [...] > + similar issue with styles & formatting where single click does not apply > the style These are the reasons is I tend to 'con'. Also most users I know are doing a single click on an object and then a right click for opening the context menu (instead of only a right click). With a change of the single click behavior these people will see a view scrolling although they don't want it.
(In reply to Ahiijny from comment #5) > Just as a point of reference, I'd like to compare the suggested > functionality with the "document map"/"navigation" in Microsoft Word and the > "document outline" in Google Docs. Many thinks for your thorough analysis, this helps a lot. I'd summarize: Navigator selection just scrolling the document is not uncommon, single click overrides double is done at some. (In reply to Ahiijny from comment #6) > ... > 1. >95% of the time, I use the navigator to quickly jump between headings in > a large document. So, single-click >>>>>>>>> double-click Vote +1, counted. (In reply to Thomas Lendo from comment #7) > Also most users I know are doing a single click on an object and then a > right click for opening the context menu (instead of only a right click). > With a change of the single click behavior these people will see a view > scrolling although they don't want it. That's the point. Ahiijny's comment suggests, however, that not too many users expect a context menu in the Navigator.
*** Bug 145669 has been marked as a duplicate of this bug. ***
> 1. >95% of the time, I use the navigator to quickly jump between headings in > a large document. So, single-click >>>>>>>>> double-click (for me, at > least). It may not seem like much of a difference, but over the course of > multiple clicks, the additional hassle of a double-click really becomes > noticeable. +1. I almost never use navigator for anything else than jumping between headings and double clicking makes it really annoying. In addition to MS World the "jump with single click" behavior is also present in Adobe Acrobat Reader when navigating PDF documents and Foxit Reader. So you could almost state that jumping is single click de facto behaviour in document navigators. I believe also that if you made a survey/questionnaire for document editor users majority would vote for single click behaviour. If single click creates issues which some writes here said there is a simple solution: introduce two different modes for navigator: "1. navigation mode", "2. edit mode". There could be a button in toolbar of navigator where you switch between the modes so everybody gets what they want.
Here is a patch that adds an expert option to make the selected entry in the Navigator scroll into document view: https://gerrit.libreoffice.org/c/core/+/126906 To enable, open the Expert Configuration dialog and set Navigator NavigateOnSelect property true. 1) menu > Tools > Options 2) LibreOffice > Advanced > Open Expert Configuration 3) Enter 'navigateonselect' and search or click org.openoffice.Office.Writer > Navigator 3) Click on the entry line with NavigateOnSelect 4) Click the Edit button to toggle between false and true 5) Click OK button 6) Click OK button again 7) Enjoy :-)
Added this to the release notes (UI/General)
(In reply to Jim Raykowski from comment #11) > Here is a patch that adds an expert option to make the selected entry in the > Navigator scroll into document view: > > https://gerrit.libreoffice.org/c/core/+/126906 > > To enable, open the Expert Configuration dialog and set Navigator > NavigateOnSelect property true. > > 1) menu > Tools > Options > 2) LibreOffice > Advanced > Open Expert Configuration > 3) Enter 'navigateonselect' and search or click org.openoffice.Office.Writer > > Navigator > 3) Click on the entry line with NavigateOnSelect > 4) Click the Edit button to toggle between false and true > 5) Click OK button > 6) Click OK button again > 7) Enjoy :-) Is there instructions anywhere how a non-programmer can install that patch? Seems a bit complicated, I don't know even where is a download button or if I should install Libreoffice from scratch? :D
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17a4f4d5e4d49189b43e748271d2d4fa330eef9b tdf#131063 Add Navigate on select expert option It will be available in 7.4.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 golemus from comment #13) > Is there instructions anywhere how a non-programmer can install that patch? > Seems a bit complicated, I don't know even where is a download button or if > I should install Libreoffice from scratch? :D Please see this page for information on how to test daily builds: https://wiki.documentfoundation.org/QA/Testing_Daily_Builds
(In reply to Jim Raykowski from comment #15) > (In reply to golemus from comment #13) > > > Is there instructions anywhere how a non-programmer can install that patch? > > Seems a bit complicated, I don't know even where is a download button or if > > I should install Libreoffice from scratch? :D > > Please see this page for information on how to test daily builds: > > https://wiki.documentfoundation.org/QA/Testing_Daily_Builds ok thanks :) Another question. I would like to customize context menu in navigator but I don't find how to do it. It is not as an option under Customize... Context Menus Tab. E.g. I would like to remove "Promote Chapter" And "Demote Chapter" options as I don't use them and they just create confusion for me. Then I would want to rename "Promote Level" to "Promote" and "Demote Level" to "Demote". Maybe also remove couple of other options from the context menu that I am not using. Is there some way to do this?
(In reply to golemus from comment #16) > Another question. I would like to customize context menu in navigator but I > don't find how to do it. It is not as an option under Customize... Context > Menus Tab. > E.g. I would like to remove "Promote Chapter" And "Demote Chapter" options > as I don't use them and they just create confusion for me. Then I would want > to rename "Promote Level" to "Promote" and "Demote Level" to "Demote". Maybe > also remove couple of other options from the context menu that I am not > using. Is there some way to do this? The Navigator code would have to be customized to do this.
(In reply to Jim Raykowski from comment #17) > (In reply to golemus from comment #16) > > Another question. I would like to customize context menu in navigator but I > > don't find how to do it. It is not as an option under Customize... Context > > Menus Tab. > > > E.g. I would like to remove "Promote Chapter" And "Demote Chapter" options > > as I don't use them and they just create confusion for me. Then I would want > > to rename "Promote Level" to "Promote" and "Demote Level" to "Demote". Maybe > > also remove couple of other options from the context menu that I am not > > using. Is there some way to do this? > > The Navigator code would have to be customized to do this. ok. Would it be difficult to implement it so that in future you could change context menu of navigator through Tools -- Customize -- Context menus? Or perhaps even the navigator toolbar (although I don't use the toolbar but I guess somebody does as it is there).
(In reply to golemus from comment #18) > ok. Would it be difficult to implement it so that in future you could change > context menu of navigator through Tools -- Customize -- Context menus? Or > perhaps even the navigator toolbar (although I don't use the toolbar but I > guess somebody does as it is there). Best to open an enhancement request for adding a way to customizing the navigator context menu directly in Writer. You can already customize the navigator context menu by manually editing the 'navigatorcontextmenu.ui' file. usr/lib/libreoffice/share/config/soffice.cfg/modules/swriter/ui/navigatorcontextmenu.ui ALWAYS GOOD TO MAKE A BACKUP COPY BEFORE MODIFYING :-) To make the promote/demote menu items not appear in the context menu either remove the following lines or set <property name="visible"> to False as I have done. <child> <object class="GtkMenuItem" id="801"> <property name="visible">False</property> <property name="can-focus">False</property> <property name="label" translatable="yes" context="navigatorcontextmenu|STR_PROMOTE_CHAPTER">Promote Chapter</property> <property name="use-underline">True</property> <accelerator key="Up" signal="activate" modifiers="GDK_CONTROL_MASK"/> </object> </child> <child> <object class="GtkMenuItem" id="802"> <property name="visible">False</property> <property name="can-focus">False</property> <property name="label" translatable="yes" context="navigatorcontextmenu|STR_DEMOTE_CHAPTER">Demote Chapter</property> <property name="use-underline">True</property> <accelerator key="Down" signal="activate" modifiers="GDK_CONTROL_MASK"/> </object> </child> <child> <object class="GtkMenuItem" id="803"> <property name="visible">False</property> <property name="can-focus">False</property> <property name="label" translatable="yes" context="navigatorcontextmenu|STR_PROMOTE_LEVEL">Promote Level</property> <property name="use-underline">True</property> <accelerator key="Left" signal="activate" modifiers="GDK_CONTROL_MASK"/> </object> </child> <child> <object class="GtkMenuItem" id="804"> <property name="visible">False</property> <property name="can-focus">False</property> <property name="label" translatable="yes" context="navigatorcontextmenu|STR_DEMOTE_LEVEL">Demote Level</property> <property name="use-underline">True</property> <accelerator key="Right" signal="activate" modifiers="GDK_CONTROL_MASK"/> </object> </child>
(In reply to Jim Raykowski from comment #19) > > You can already customize the navigator context menu by manually editing the > 'navigatorcontextmenu.ui' file. OK. I just realized another issue which is related. When opening the navigator tree structure as default is folded. In MS Word the tree structure is always completely unfolded/open. In Libre Navigator you usually have to make a lot of unneccessary clicks to first open a folder and then click a sub-branch. Of course in some use cases folded structure might make more sense (if you have very complex hierarchy and long document). But I would claim that in majority of use cases people would prefer default behavior where document is A. either completely unfolded/open, or B. headings1 and headings2 are visible but headings3 are folded. Best solution would be that the state of navigator view would be saved within the document but I don't know if this is easy to implement or even possible with docx format. 1. Easiest solution would be to change default behavior to A or B above. 2. a bit more difficult solution would be to add a drop-down menu to navigator where user can choose TREE-DEPTH + default TREE-DEPTH to Options/Settings. TREE-DEPTH = 1: headings1 are visible, headings2 are not visible TREE-DEPTH = 2: headings1 and headings2 are visible, headings3 are not visible etc... What do you think?
(In reply to Heiko Tietze from comment #12) > Added this to the release notes (UI/General) If I am not wrong, this option is not available in 7.3, only in current master (7.4). Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #21) > If I am not wrong, this option is not available in 7.3, only in current > master (7.4). Moved it to 7.4.