Download it now!
Bug 129471 - UI-Writer: Increase the size of window for Navigate by in the Find toolbar, plus consider ordering of items
Summary: UI-Writer: Increase the size of window for Navigate by in the Find toolbar, ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0 target:7.1.0
Keywords: difficultyMedium, easyHack, skillCpp, topicUI
Depends on:
Blocks: Find-Toolbar Navigate-By
  Show dependency treegraph
 
Reported: 2019-12-18 13:57 UTC by sdc.blanco
Modified: 2021-01-27 08:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2019-12-18 13:57:44 UTC
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)
Comment 1 Dieter 2020-01-21 16:47:34 UTC
I also can't see an order.

cc: Design-Team for further input
Comment 2 Heiko Tietze 2020-01-22 10:39:53 UTC
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.
Comment 3 sdc.blanco 2020-01-22 10:52:58 UTC
(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"?
Comment 4 Heiko Tietze 2020-01-22 14:03:51 UTC
(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.
Comment 5 V Stuart Foote 2020-01-22 17:32:23 UTC
+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
Comment 6 V Stuart Foote 2020-01-22 17:43:47 UTC
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?
Comment 7 sdc.blanco 2020-01-23 08:39:56 UTC
(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).
Comment 8 Heiko Tietze 2020-01-23 09:47:53 UTC
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
Comment 9 Jim Raykowski 2020-01-23 22:21:52 UTC
(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.
Comment 10 Jim Raykowski 2020-01-24 21:40:39 UTC
(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
Comment 11 Commit Notification 2020-03-13 21:45:24 UTC
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.
Comment 12 Xisco Faulí 2020-07-22 15:09:39 UTC
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
Comment 13 Shivam Kumar Singh 2020-07-22 15:29:23 UTC
(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.
Comment 14 sdc.blanco 2020-09-26 14:59:08 UTC
(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?
Comment 15 Shivam Kumar Singh 2020-09-26 15:03:31 UTC
(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?
Comment 16 V Stuart Foote 2020-09-26 15:17:56 UTC
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
Comment 17 sdc.blanco 2020-09-26 16:54:18 UTC
(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
Comment 18 Commit Notification 2020-09-28 08:24:38 UTC
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.