In the LO Writer Navigator, one of the button limits the display of items to the currently "Selected Category" - where the top of the Navigator dialog lets you select a category of items. Unfortunately, when you press the button, the category you see is _not_ the one selected in the top menu-button, but rather the one containing the currently-selected item in the navigation tree. That's not what the user would expect. This should be reconciled in one of two ways: 1. Change the selected category when an item is selected in the navigation tree, or 2. When limiting display, respect the category selected in the top menu-button. I'm partial to option (2.) myself. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: fb9270b238cba4f36e595c5d7f4d85f6f3f18e1c CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
Hi Eyal, I think you may be confusing the categories in the 'Navigate By' control with the categories in the Navigator tree.
(In reply to Jim Raykowski from comment #1) > I think you may be confusing the categories in the 'Navigate By' control > with the categories in the Navigator tree. 1. That control has no name visible to the user. It is simply the category selection control. 2. It's not _me_ that's confusing things, it's the _UI_ that's confusing them.
(In reply to Eyal Rozenberg from comment #2) > 1. That control has no name visible to the user. It is simply the category > selection control. > It's the 'Navigate By' control and there is a tooltip that appears when the mouse pointer is on it that says 'Navigate By'. > 2. It's not _me_ that's confusing things, it's the _UI_ that's confusing > them. There are several categories in the 'Navigate By' drop down that are not in the content tree. 'Page', 'Recency', 'Reminder', 'Repeat Search', 'Control', 'Graphics', 'Field by type', 'Table Formula', 'Wrong table formula'. The two buttons to the right of the control 'Next [category]' and 'Previous [category]' are used to move to the next or previous category position in the document. There is helpful information about this in the Writer Guide 7.2 https://books.libreoffice.org/en/WG72/WG7201-IntroducingWriter.html#toc48
I neither understand the problem nor the expectation. With "Select Category" you mean the top-left dropdown that lists "Bookmark, Comment, Control..." and with "limits the display of items" the right-most in the second row with the tooltip "Heading Levels Shown"? And you expect the two being related to each other?
(In reply to Heiko Tietze from comment #4) > It's the 'Navigate By' control No it isn't. That is, if the UI doesn't make it clear that that's what it is, then it isn't. > and there is a tooltip that appears when the > mouse pointer is on it that says 'Navigate By'. But the user does not need a tooltip to conclude that it is the Category selection control. > There are several categories in the 'Navigate By' drop down that are not in > the content tree. 'Page', 'Recency', 'Reminder', 'Repeat Search', 'Control', > 'Graphics', 'Field by type', 'Table Formula', 'Wrong table formula'. It's not impossible that the category selection would have some non-category items. Also, some of these items sound like bona-fide categories: 'Control', 'Reminder', 'page', 'Graphics', 'Table Formula' and 'Wrong Table Formula', and since the content tree is typically very big, and expanded, one tends to believe that either those items appear later in the tree, or you just don't have them in the document. > The two > buttons to the right of the control 'Next [category]' and 'Previous > [category]' are used to move to the next or previous category position in > the document. Now that you mention it, those Up and Down buttons are quite confusing. When you press them, the position in the document changes, but the position in the content tree doesn't always change - sometimes it does, sometimes it doesn't. And sometimes an entry in the content tree becomes selected, while sometimes the selection is lost. Also, the tooltips say "Continue Search Forward" and "Continue Search Backwards" even though you're not in the middle of any search. > There is helpful information about this in the Writer Guide 7.2 The UI should be clear and consistent without requiring reading the guide.
(In reply to Heiko Tietze from comment #4) > with "limits the display of items" [, do yo mean] the right-most in the second > row with the tooltip "Heading Levels Shown"? No, I mean the leftmost button in the second row, with the two inwards-facing orange arrows, and the tooltip "Switches between the display of all categories and the selected category". > I neither understand the problem nor the expectation. With "Select Category" > you mean the top-left dropdown that lists "Bookmark, Comment, Control..." Yes. I realize that it is not the developers'/dialog designers' intent for that control to mean only "Navigate By" rather than "Select Category for limiting displayed items", but the user of this dialog would typically not make this distinction, and would assume that: Category selected in Navigation dialog top control = Selected Category in context of navigation = Category to navigate by If this is not the intent, a distinction should be made clear, as should the identity of the currently "selected" category". Frankly, though, even this intent seems suspect to me and I would reconsider it.
We have plenty of tickets regarding the Navigator UI. It's a typical feature-creep example with overloaded functions and unclear use cases. And we cannot change it without making many users angry due to missing features. (In reply to Eyal Rozenberg from comment #6) > No, I mean the leftmost button in the second row, with the two > inwards-facing orange arrows, and the tooltip "Switches between the display > of all categories and the selected category". Second row, left-most item is "Content Navigation View". I likely use a different icon theme (Karasa Jaga is my preference) and arrows are omnipresent in icon designs anyway.
Created attachment 178693 [details] A navigator window @Heiko, hopefully this will clarify which buttons I'm talking about... second row on the left, above the selected 'v', with two orange arrows facing inwards.
(In reply to Heiko Tietze from comment #7) > We have plenty of tickets regarding the Navigator UI. It's a typical > feature-creep example with overloaded functions and unclear use cases. I guess that must be it... > And > we cannot change it without making many users angry due to missing features. Well, I'm not suggesting adding or removing any features. But let me rephrase the two options I've suggested in light of the comments by Jim and yourself: 1. Add a label indicating that the top menubutton is "Navigate By" or "Search By"; and perhaps even add a separator between the top row and the rest of the window, to make it clear that the menubutton does not select a category. 2. Whenever the user clicks an item in the content tree, that item's category is also selected in the top menubutton, and vice-versa - when you select an item that's also a Category in that menubutton, it's selected also in the content tree. 3. Like option (2.), but partial: menubutton affects content tree selection but not vice-versa; that would make it easier to continue searching in the same way despite manually trying out specific items in the tree. Option (1.) really doesn't change any functionality. Options (2.) and (3.) change behavior, but you do not lose the ability to do anything you were doing before, nor gaining a new ability.
(In reply to Eyal Rozenberg from comment #8) > ...second row on the left, above the selected 'v', with two orange arrows > facing inwards. "Content Navigation View" (and this string hasn't changed in years) Version: 7.3.1.3 / LibreOffice Community Build ID: 30(Build:3) CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.3.1-1 Calc: threaded
Created attachment 178792 [details] gtk3 screenshot
Created attachment 178793 [details] x11 screenshot
Created attachment 178794 [details] qt screenshot
We discussed the topic in the design meeting. Adding a label before the dropdown occupies a lot of space (as Jim's screenshots clearly show). Too much. And having the label above stacks quite a lot controls before the actual content. But if we implement that picking an entry in the Navigator list selects the appropriate item in the "Navigate By" dropdown, and vice versa, the workflow might be easier to understand. The mutual selection is not always possible, for example "Repeat Search". And it makes sense to match the two lists and have the same order and names (for example Graphics vs. Images). Those items that are only available in the "Navigate By" dropdown could be shown after a separator line. I wonder if the "Go To Page" control can be replaced by "Page". Feels as if I asked this before. But we could get rid of one extra UI element and have a cleaner UI.
(In reply to Heiko Tietze from comment #14) > We discussed the topic in the design meeting. You should really consider asking discussion-responsive bug reporters to join a design meeting when something is planned to comone up... it worked well last time. Also, I hope there were more than 1 or 2 people at the meeting. > But if we implement that picking an entry in the Navigator list selects the > appropriate item in the "Navigate By" dropdown, and vice versa, the workflow > might be easier to understand. Yes. That would be quite satisfactory AFAIAC. > The mutual selection is not always possible, for example "Repeat Search". Yes, although in such cases, the other selection could perhaps be cleared. > And it makes sense to match the two lists and > have the same order and names (for example Graphics vs. Images). Those items > that are only available in the "Navigate By" dropdown could be shown after a > separator line. Oh, that's a nice idea! > I wonder if the "Go To Page" control can be replaced by "Page". What "Go To Page" control? Anyway, that sounds like a separate bug to file.
(In reply to Eyal Rozenberg from comment #15) > (In reply to Heiko Tietze from comment #14) > > We discussed the topic in the design meeting. > > You should really consider asking discussion-responsive bug reporters to > join a design meeting when something is planned to comone up... it worked > well last time. Also, I hope there were more than 1 or 2 people at the > meeting. Please follow the mailing list where I announce topics, usually at Tuesday. And minutes with a list of participants are shared too after the meeting. https://wiki.documentfoundation.org/Design/Mailing_List
(In reply to Heiko Tietze from comment #14) > But if we implement that picking an entry in the Navigator list selects the > appropriate item in the "Navigate By" dropdown, and vice versa, the workflow > might be easier to understand. The mutual selection is not always possible, > for example "Repeat Search". And it makes sense to match the two lists and > have the same order and names (for example Graphics vs. Images). Those items > that are only available in the "Navigate By" dropdown could be shown after a > separator line. Oh, please no, don't do it. Anyway, my personal PoV here is: there are tooltips for the both controls... I don't think we need something other there
(In reply to Roman Kuznetsov from comment #17) >> ... picking an entry in the Navigator list ... selects the >> appropriate item in the "Navigate By" dropdown, and vice versa... > Oh, please no, don't do it. Please elaborate your aversion.
Created attachment 178992 [details] demo or patch to relate Navigate By control to Content tree in Navigator Greetings All, Here is an enhancement patch that relates the Navigate By control to the Content tree. Gtk3 doesn't work with the first stab (see patchset 2) although it possibly works with Gtk4. Patchset 3 works around the gtk3 issue. https://gerrit.libreoffice.org/c/core/+/131874
(In reply to Jim Raykowski from comment #19) > Created attachment 178992 [details] > demo or patch to relate Navigate By control to Content tree in Navigator > > Greetings All, > > Here is an enhancement patch that relates the Navigate By control to the > Content tree. Gtk3 doesn't work with the first stab (see patchset 2) > although it possibly works with Gtk4. Patchset 3 works around the gtk3 > issue. > > https://gerrit.libreoffice.org/c/core/+/131874 Will I can disable that behaviour? For example, I want use the top control for select/navigate tables, but in the same time I want to see Headings in Navigator list, but not tables
(In reply to Jim Raykowski from comment #19) > Created attachment 178992 [details] > demo or patch to relate Navigate By control to Content tree in Navigator Amazing!
Created attachment 179020 [details] Navigating tables with Navigate By when in Headings content navigation view (In reply to Roman Kuznetsov from comment #20) > Will I can disable that behaviour? > For example, I want use the top control for select/navigate tables, but in > the same time I want to see Headings in Navigator list, but not tables For this you can put the Navigator in Headings content navigation view and use the Navigate By control for tables. Please see attached demo.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/91be53fc5e72042f4741ab8b85e831df868adf82 tdf#147807 SwNavigator: relate Navigate By control to Content tree 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 Heiko Tietze from comment #21) > Amazing! Props to Eyal!