Ctrl-F (Find Toolbar, with Navigate by) 1. Increase size (height) of drop-up window for "Navigate by" in Find toolbar. (Presumably the number of elements has increased over time, so that now one needs to scroll up/down to see all the possibilities.) 2. Consider whether the ordering of the elements in "Navigate By" can/should be improved. (e.g. - Table is the first item, while Table Formula is the last - Drawing is not grouped with Graphics and OLE Object - maybe Section should be with Text Frame - or maybe alphabetical ) I do not have an opinion about the ordering principle -- but it might deserve some attention to whether the "logic" of the presentation can be improved. (also tested in LO 6.4.0.0.beta1)
I also can't see an order. cc: Design-Team for further input
I vote for removing the navigation from the quick find bar. If we keep it, it makes sense to sort. However I disagree with enlarging as the common rule for such a menu is to scroll with more than 8 items. Long lists are not usable anyway.
(In reply to Heiko Tietze from comment #2) > I vote for removing the navigation from the quick find bar. "Navigate by" is a UNO. Users can add/remove with Tools>Customize. Did you mean not present as "default"?
(In reply to sdc.blanco from comment #3) > "Navigate by" is a UNO. Users can add/remove with Tools>Customize. You are right, the power of customizability :-). So let's hide by default- and fix the issue.
+1 for keeping the navigate by with the Find bar, but hiding it by default (for Eve users to set enabled with toolbar Visible button). As to sorting, IIUC the listbox for .uno:NavElement was taken from sequence in the the Navigator's Navigation floating toolbox. Caolán has removed the toolbox dialog (against bug 130004) [1] but keeping the old sequence, and Jim has a patch up for review [2] to now use the same .uno:NavElement control replacing the toolbox on the Sidebar, but still with the old sequence. Believe we are free to reorder the listbox sequence. But for UX we would need to consider any change of sequence affects both the Find bar and the Navigator. What is the best order then? An alpha sort would not necessarily be best. Needs functional grouping (add separators maybe). =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/86874 [2] https://gerrit.libreoffice.org/c/core/+/87005
As to increasing the height of the listbox, either Find bar or Navigator, we have 18 entries and a scroll bar. I could see dropping the scroll bar and increasing the height of the list box to show all current entries. Selection from the listbox is already keyboard accelerated (first letter), but does the list need managed (no conflict) accelerators? E.g. 'T' now hits Table - Text Frame - Table formula; need unique values?
(In reply to Heiko Tietze from comment #2) > the common rule for such a menu is to scroll with more than 8 items. So I won't tell you that it is currently at a usable 13 (-: 1. Some items may deserve being dropped: (i) Repeat search (needed here?) (ii) Selection (does it work?) 2. If scrolling will remain (in more rational ordering), have most/more commonly used choices visible when listbox is opened (i.e., the ones shown without need for scrolling).
So let's do: * sort alphabetically * show all entries (and decide then if we go back to scrollbar) * hide NavigateBy, the accompanying next/prev, and also the button for the search dialog by default * the width of the NavigateBy dropdown is IMHO defined by the content; no objection if we can make it larger but it has to be responsive to the potentially longer content after translation
(In reply to sdc.blanco from comment #7) > 1. Some items may deserve being dropped: > (i) Repeat search (needed here?) > (ii) Selection (does it work?) > AFAIK Selection navigation works in the order selections are made, not by order of occurrence in the document.
(In reply to Heiko Tietze from comment #8) > So let's do: > Code pointers: > * sort alphabetically Arrays to alphabetize are here: sw/source/uibase/ribbar/workctrl.cxx aNavigationInsertIds[] aNavigationImgIds[] aNavigationStrIds[] STR_IMGBTN_ARY[] Defines are here: sw/source/uibase/inc/workctrl.hxx > * show all entries (and decide then if we go back to scrollbar) see: core/include/vcl/lstbox.hxx void ListBox::SetDropDownLineCount and: sw/source/uibase/ribbar/workctrl.cxx NavElementBox_Impl constructor > * hide NavigateBy, the accompanying next/prev, and also the button for the > search dialog by default > findbar.xml (there are two versions) see: sw/uiconfig/swriter/toolbar/standardbar.xml for example how to hide toolbar items > * the width of the NavigateBy dropdown is IMHO defined by the content; no > objection if we can make it larger but it has to be responsive to the > potentially longer content after translation see: sw/source/uibase/ribbar/workctrl.cxx NavElementBox_Impl constructor
Shivam Kumar Singh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/26c9b7863b7e3a8f3a1c43ec26f2efe77c1958a7 tdf#129471 alphabetize Navigate By option in writer It will be available in 7.0.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.
A polite ping to Shivam Kumar Singh: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
(In reply to Xisco Faulí from comment #12) > A polite ping to Shivam Kumar Singh: > Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Partially fixed > Otherwise, Could you please explain what's missing? W.R.T comment 0, point number 2 (reordering of elements) have been merged point number 1(increasing the size of the Navigate by) is yet to be done. I am currently busy in something else so cannot look into this for sometime, removing the assigned status for now, but i will try to fix it once i am free.
(In reply to Xisco Faulí from comment #12) > Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? > Otherwise, Could you please explain what's missing? The original motivation for the request is satisfied. (Thanks Shivam! Looks great, much easier to use.) Maybe this bug should be closed, and any remaining issues -- which were generated in the discussion here -- be opened as a new bug. Here is a status review. (In reply to Heiko Tietze from comment #8) > So let's do: > * sort alphabetically DONE > * show all entries (and decide then if we go back to scrollbar) DONE > * hide NavigateBy, the accompanying next/prev, and also the button for the > search dialog by default ?? (new bug report?) > * the width of the NavigateBy dropdown is IMHO defined by the content; no > objection if we can make it larger but it has to be responsive to the > potentially longer content after translation ?? looks ok to me. One of the entries "Wrong table formula" is much longer than all the others, so it gives lots of whitespace (and room for translation) I could not understand Shivam's additional concerns in comment 13. Maybe there are additional bug reports to file for that?
(In reply to sdc.blanco from comment #14) > > I could not understand Shivam's additional concerns in comment 13. Maybe > there are additional bug reports to file for that? The bug was also about "Increase the size of window for Navigate by in the Find toolbar"(the heading of this bug). In my patch I sorted the contents but no change was done to the size of the Navigate by. Should we consider that or the current situation is acceptable?
With current master, we get the full listbox height of 18 entries--no scroll bar. So listbox size and ordering seem fine, and are consistent on Find bar and in the Navigator Navigate-by. IMHO => Resolved Fixed
(In reply to sdc.blanco from comment #14) > > * hide NavigateBy, the accompanying next/prev, and also the button for the > > search dialog by default Thanks to Jim's code pointers....the following patch hides the NavigateBy, and next/prev icons in the Find toolbar. If this seems ok, then I will push it. https://gerrit.libreoffice.org/c/core/+/103429
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e70069fb72d52c20b28166708a217bf674dcb61b tdf#129471 change defaults on Find toolbar It will be available in 7.1.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.