The Navigator adjusts itself to the proper Navigator category (e.g. H Heading) associated to the current editing position. The item belonging to the edit position in the Edit window gets highlighted in the Navigator. Fortunately Navigator also unhides the respective element (rather than highlighting the last shown ancestor of the to be highlighted one). Always showing the corresponding position from the Edit window in the Navigator has long been missing and it is very useful. It can happen, that the highlighted item in the navigator window depends on other items and it is shown as the first line in Navigator's own window. In order to really oversee the context, I see myself often vertically readjusting the navigator window. I propose, to always center the highlighted item with respect to navigator's window. If that's too difficult, then at least show two items above the highlighted one (if there are at least two of them, of course). Steps to reproduce 1. Open a file with a large Hierarchy of headlines (e.g. an instruction manual) 2. Unselect "Content Navigation View" if it happens to be selected. 3. Select H Headings in the Navigator. 4. Position the editing focus to the very end of the document with the mouse cursor 5. Position it to some second or third level heading's text body far above with the mouse. Result The corresponding heading gets highlighted. But it is the topmost element in the Navigator window. In order to see the hidden context above it, one has to scroll Navigator's window manually. Expected behavior At least some of the parent categories of the highlighted item shall be visible in the Navigator (if there is enough space).
I confirm the actual behaviour and I support enhancement request Version: 7.3.4.1 (x64) / LibreOffice Community Build ID: 13668373362b52f6e3ebcaaecb031bd59a3ac66b CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Jim, what do you think about it? Is it feasible? Can we change status to NEW?
Hi Adalbert and Dieter, Here is a link to an enhancement patch that shows at least two headings above tracked heading when the tracked heading is automatically scrolled into view: https://gerrit.libreoffice.org/c/core/+/136436
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8e8e0aefc998adba749a93cacc4660d859fba675 tdf#149279 SwNavigator enhancement to show at least two headings It will be available in 7.5.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/4d1a9a76a1dbef9d177e55d6fc9b294a6dafe33f tdf#149279 SwNavigator enhancement to show at least two headings It will be available in 7.4.0.0.beta2. 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 181032 [details] Test playground to test the feature, showing where it still should be improved Preliminary conclusion: Opening necessary subcategories of headings and highlighting them seems to work. But the navigator-window should always be scrolled, such that the highlighted line plus the two above it shall be really on display rather below or above the shown window. Of course, only if the additional lines really fit to the window: Navigator's window might be not high enough to show three headlines: In this case at least the highlighted headline and as much as possible above it shall be on display: after automatically scrolling Navigator's window accordingly.
(In reply to Adalbert Hanßen from comment #5) > Created attachment 181032 [details] > Test playground to test the feature, showing where it still should be > improved Hi Adalbert, I see in the test playground file you are using gtk3. I noticed gtk3 does not behave the same as the vcl gen/x11 backend when the heading to be scrolled into view is not visible in the navigator and is below the currently highlighted heading in the Navigator tree. This is due to how scroll_to_row is handled by gtk3. "The tree does the minimum amount of work to scroll the cell onto the screen. This means that the cell will be scrolled to the edge closest to its current position."[1] Here is a link to a patch that makes GtkInstanceTreeView scroll_to_row more SalInstanceTreeView scroll_to_row like: https://gerrit.libreoffice.org/c/core/+/136934 [1] https://docs.gtk.org/gtk3/method.TreeView.scroll_to_cell.html
(In reply to Jim Raykowski from comment #6) > ... > > Here is a link to a patch that makes GtkInstanceTreeView scroll_to_row more > SalInstanceTreeView scroll_to_row like: > https://gerrit.libreoffice.org/c/core/+/136934 > > [1] https://docs.gtk.org/gtk3/method.TreeView.scroll_to_cell.html Jim, thank you for your explanation (which I have to admit I don't understand because that's too high for me). Is there a general description how I would have to apply your patch? Or is it necessary to download all the source code and compile it (which I might achieve, but once something does not work at once I probably will have to give up lacking understanding at that level). The alternative would be to wait until your correction has found its way into a built development version.
(In reply to Adalbert Hanßen from comment #7) > Is there a general description how I would have to apply your patch? Or is > it necessary to download all the source code and compile it (which I might > achieve, but once something does not work at once I probably will have to > give up lacking understanding at that level). It would be necessary to download the source code and apply the patch. Instructions on how to build are here: https://wiki.documentfoundation.org/User:Hossein/Build After successfully building one way to apply the is the following: git fetch https://git.libreoffice.org/core refs/changes/34/136934/1 && git checkout FETCH_HEAD && git rebase master make vcl SAL_USE_VCLPLUGIN=gtk3 ./instdir/program/soffice.bin > The alternative would be to wait until your correction has found its way > into a built development version. There is a way to see the current difference in behavior between gtk3 and x11 by using nightly builds and the SAL_USE_VCLPLUGIN environment variable. For me, the deb nightly build (https://dev-builds.libreoffice.org/daily/master/current.html) places a link to the program executable in /usr/local/bin. Enter the following on the command line will use the x11 VCL backend: SAL_USE_VCLPLUGIN=gen /usr/local/bin/<name of nightly build>
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3c8e81669f2311dd35aa6787cbf3e5a6a0520433 tdf#149279 related: make gtk treeview scroll_to_row more sal like It will be available in 7.5.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 181322 [details] revisited test procedure, like the last upload, but now vor the new version
(In reply to Commit Notification from comment #9) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 3c8e81669f2311dd35aa6787cbf3e5a6a0520433 > > ... > > Affected users are encouraged to test the fix and report feedback. I have tested it with today's development version. Two minor glitches are left over. One of them deals with the button Content Navigation View. See test document of comment 10 (which is a revised version of the old one: I went to all prior tests and watched for differences and documented them with screenshots). The file has tracked changes in it, so it is quickest to look at it showing only the final version.
In reference to comment 10 test document: "I switched on the Navigator and selected the display of Headings In order to be able to latch the shown button, the highlight must be on Headings: Otherwise the button will not latch and then these tests go wrong in the parts located within tables!" If "Tables" content type or a table content type entry is the Navigator cursor entry (highlighted entry) when the Content Navigation View button is pressed the Navigator will switch to Table navigation view. Likewise with other content types. The "Navigate By" button is not what determines the content type for Content Navigation View to switch to. The cursor entry (highlighted entry) is what determines this. "Then, when in the text window, I pressed Strg-Pos1 to go to the top of the document. Same bug as before, scrolling in the Navigator window is still forgotten in this particular situation:" I am guessing Strg-Pos1 is equivalent to Ctrl-Home. This moves the cursor to the top of the document, which is not a Heading or content of a Heading therefore there is nothing for the Navigator to track which is the reason for no highlighted heading or scrolling.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/53d5f5e15c005d95fa8c9d24d98e26afd2ca2103 tdf#151387 Fix regression cause by tdf#149279 It will be available in 7.5.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/d19d64b6a3e697fdbf7c0d05a318afddbc349bd4 tdf#151387 Fix regression cause by tdf#149279 It will be available in 7.4.3. 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 187581 [details] A LO Writer document showing the bug with screenshots and proposing how to solve it Bug 149279 seems to be back (or not having been completely eradicated) in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: b76a3bdc996f275f9d615b32d6ab89d533a7505c CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded How to reproduce the bug: See the attached odt document I also proposes how to overcome the bug.
I repro the table tracking not moving the table entry into the visible view of the content tree bug. It seems to only affect gtk3. Table tracking can be turned off using the table content context menu but that will not make the headings track when the cursor is in a table. The navigator can be made to show only headings content using the content navigation view button. In the sidebar version of the Navigator it is the first button on the second line of controls in the toolbox above the content view. This will make headings be tracked when the cursor is in a table.
(In reply to Jim Raykowski from comment #16) > I repro the table tracking not moving the table entry into the visible view > of the content tree bug. It seems to only affect gtk3. > > ... In the sidebar version of the Navigator it is the > first button on the second line of controls in the toolbox above the content > view. This will make headings be tracked when the cursor is in a table. You may have notices, but why is the sidebar Navigator different from the undocked one? I had a situation with two Navigator windows, one docked and an undocked one. The undocked one behaved as you described. The docked version switched between categories rather arbitrarily: It even happened that only Sections were shown, although only Headings were selected! The category Headings could not even be made visible without closing the Navigator and opening it again. This happened in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 70fd835b4cf75e386ee115c705241a4059fb68a8 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
Created attachment 187681 [details] Screenshots showing the remaining problem (In reply to Jim Raykowski from comment #16) > ... > Table tracking can be turned off using the table content context menu but > that will not make the headings track when the cursor is in a table. > > The navigator can be made to show only headings content using the content > navigation view button. In the sidebar version of the Navigator it is the > first button on the second line of controls in the toolbox above the content > view. This will make headings be tracked when the cursor is in a table. Jim's advice only works if the right sequence of steps is taken. As a side-effect I found a place in the description which should be improved. See attached document with screenshots.
(In reply to Adalbert Hanßen from comment #17) > You may have notices, but why is the sidebar Navigator different from the > undocked one? Other than the List Box On/Off button, 3rd line first control in the Navigator toolbox under the 'Content Navigation View' button, they should behave the same. Possibly tracking of certain categories was turned off in one and not the other. This can happen when both are open. Category tracking settings are are not uniquely saved for the sidebar and floating version. The settings for the version that is closed last are used when the Navigator is reopened. > I had a situation with two Navigator windows, one docked and > an undocked one. The undocked one behaved as you described. The docked > version switched between categories rather arbitrarily: It even happened > that only Sections were shown, although only Headings were selected! Sections are tracked before Headings. Section tracking can be turned off in the Section content context menu by right click on the Section category or a section entry in the Navigator content tree. > The category Headings could not even be made visible without closing the > Navigator and opening it again. Not even with the scroll bar? I believe this is a gtk3 issue.
Created attachment 187705 [details] response to Screenshots showing the remaining problem @Adalbert, please see the attached for response to questions in the 'Screenshots showing the remaining problem' document.