Bug 79167 - UI: Opening the new "navigate by" for choosing the object to go back&forth opens the "big" navigation window, too
Summary: UI: Opening the new "navigate by" for choosing the object to go back&forth op...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.0.beta1
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.5.0 target:6.0.0
Keywords: difficultyBeginner, easyHack, skillCpp
: 96483 107352 (view as bug list)
Depends on:
Blocks: Find-Toolbar
  Show dependency treegraph
 
Reported: 2014-05-24 07:02 UTC by riesslibo
Modified: 2018-02-20 13:24 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
mockup (13.63 KB, image/png)
2017-05-31 17:01 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description riesslibo 2014-05-24 07:02:27 UTC
This is a little bit confusing for a (new) user, because there are now two places to choose object typs for navigation, he rather knows that the "big" navigation window is for direct navigation and the little one for choosing the object typ for the navigation arrows in the search&find symbol bar.
BTW, there are three different places to navigate in a document now, a symbol bar "Navigation" with back&forth, the navigation via different object types with back&forth and the "big" navigation window (free floating or at the side) with direct navigation to one obejct. 
I propose the "enhancement" (it is not a bug, but a little bit irritating) to consolidate the different features to navigate through a document in the big navigation window.
Comment 1 Joel Madero 2014-05-24 17:04:23 UTC
Asking for UX advice on this one. Thanks for reporting :)
Comment 2 sophie 2014-05-25 14:01:43 UTC
Hi, confirmed, for me it's a bug because if you have several workspaces open, it
has the effect to switch the view to another workspace because the
Navigator window is moved between two workspaces. Sophie
Comment 3 Marina Latini (SUSE) 2014-05-25 22:13:41 UTC
Confirmed on LibreOffice:
* Version: 4.3.0.0.beta1
* Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f
LibreOffice installed with fresh user profile with Italian langpack and helppack.

OS: Ubuntu 13-10 x86_64
unity --version: unity 7.1.2

Steps to reproduce:
1) Open a new Writer document 
2) Fill it with text, tables, pictures, comments... 
3) Open the Find bar from Edit -> Find 
4) Click on "Navigate by" button

LibreOffice is still open but another workspace gets the focus
Comment 4 Jean-Baptiste Faure 2014-06-05 04:41:20 UTC
I agree with Sophie, it is a bug. In LO 4.3.0.0.beta2+ under Ubuntu (Unity window manager with 2 x 2 workspaces), I get both the small navigation toolbar and the Navigator window if it is closed. What is the most frustrating is that the small navigation toolbar always opens on another workspace.

Reset importance to normal and component to Writer.

Best regards. JBF
Comment 5 Jean-Baptiste Faure 2014-06-05 04:52:03 UTC
Hi Samuel,

It seems that your change on navigation toolbar has some weird side effect. Please could you have a look ?

Best regards. JBF
Comment 6 Samuel Mehrbrodt (allotropia) 2014-06-07 11:49:40 UTC
Sorry I don't have the time for this currently.
But this might be an easy hack.
Here's the code that gets executed when clicking the "Navigate by" button: http://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view2.cxx#1060

This commit removed the old buttons from the scrollbar: http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e8fe4d8e19be2ccd8f5bb898530e2f615a90321
And this commit added the buttons to the find bar: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0f86895fcd1001324974d644a728152b97b22ab0

So to show only the small element selector window when clicking the "Navigate by" button, you need to reintroduce the code that was removed in the first commit ("SwNaviImageButton::Click" is the start point).
Comment 7 Björn Michaelsen 2014-12-02 10:53:09 UTC
adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 8 Harald Koester 2014-12-13 22:41:36 UTC
I observed a strange behaviour allready before the move of the "Navigate by" button to the find bar (see bug 43220). I would expect that the navigation bar is displayed if the "Navigate by" button is clicked once and it will be closed again if the button is clicked again. But this has not worked correctly neither before the move nor in version 4.3.
Comment 9 Yousuf Philips (jay) (retired) 2015-05-27 19:49:51 UTC
In bug 89566, i've suggested the reorganization of the navigator window/sidebar, which included the inclusion of the navigation window buttons into the window/sidebar by having it as a drop down (attachment 113625 [details]), so it might be useful to include the same drop down as a control in the toolbar.
Comment 10 Robinson Tryon (qubit) 2015-12-13 10:58:00 UTC Comment hidden (obsolete)
Comment 11 Robinson Tryon (qubit) 2016-02-18 14:51:55 UTC Comment hidden (obsolete)
Comment 12 riesslibo 2016-04-22 12:29:12 UTC
Tested with V5.2.0.0 alpha x86 in Win7x64 German localisation:
  
Still two different workspaces via sidebar and "navigate to" from the Search&Replace Toolbar.
You are able to click different objects in one of them, the focus is set to the clicked object, but in the other navigator workspace the active object isn't refreshed and correctly highlighted.
Comment 13 Harald Koester 2016-08-30 13:40:47 UTC
Just thougt again about this problem. 

Wouldn't it be better, if the "Navigate by" button is moved from the Find bar to the Navigate bar. Just the name says this already, that this is more correct. 

If you like to have an object specific search in the find bar, you can look there for an object with the exact name (e.g. find 'Table1'). But this would be already a significant enhancement of the find function. For me the fixing of this bug has a higher a priority.
Comment 14 Miklos Vajna 2017-05-29 15:29:12 UTC
Discussing this offline with Marina, and checking the current behavior on master, the first thing to fix here would be to open the navigator on the sidebar, not as a separate window, to be consistent with e.g. the style panel, which is also opened there.
Comment 15 Commit Notification 2017-05-29 21:29:44 UTC
Francesco Gradi committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1955bb1172508b2bf3c7476de241834ae7771359

Related: tdf#79167 sw: open the navigator in sidebar from the findbar

It will be available in 5.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Yousuf Philips (jay) (retired) 2017-05-30 06:53:36 UTC
(In reply to Miklos Vajna from comment #14)
> Discussing this offline with Marina, and checking the current behavior on
> master, the first thing to fix here would be to open the navigator on the
> sidebar, not as a separate window, to be consistent with e.g. the style
> panel, which is also opened there.

Ideally a user shouldnt to forced to open the navigator at all in order to modify the navigate by option, as they would have to be forced again to close the navigator.
Comment 17 sophie 2017-05-31 13:14:08 UTC
(In reply to Yousuf Philips (jay) from comment #16)
> (In reply to Miklos Vajna from comment #14)
> > Discussing this offline with Marina, and checking the current behavior on
> > master, the first thing to fix here would be to open the navigator on the
> > sidebar, not as a separate window, to be consistent with e.g. the style
> > panel, which is also opened there.
> 
> Ideally a user shouldnt to forced to open the navigator at all in order to
> modify the navigate by option, as they would have to be forced again to
> close the navigator.

The Navigate by option should recover the labels of the objects by which navigation is possible in the Find toolbar, that way you don't have to open/close the Navigator - Sophie
Comment 18 Yousuf Philips (jay) (retired) 2017-05-31 17:01:41 UTC
Created attachment 133755 [details]
mockup

As mentioned in comment 9, the most ideal solution is for the user not to have to open up the navigation dialog and simply change the search type through a drop down menu control.
Comment 19 sophie 2017-06-01 08:55:29 UTC
(In reply to Yousuf Philips (jay) from comment #18)
> Created attachment 133755 [details]
> mockup
> 
> As mentioned in comment 9, the most ideal solution is for the user not to
> have to open up the navigation dialog and simply change the search type
> through a drop down menu control.

Great, super great, this is exactly what we need :) Sophie
Comment 20 Yousuf Philips (jay) (retired) 2017-06-24 20:38:41 UTC
*** Bug 107352 has been marked as a duplicate of this bug. ***
Comment 21 Jim Raykowski 2017-07-20 20:12:54 UTC
I've got the drop down list toolbar control enhancement part working. 

Looking into updating the small navigation box item checked and label when navigation element is changed in the toolbar control and vice versa.

Also to make ScrollToPrevious and ScrollToNext controls quick help change in relation to navigation element selected instead of generic 'Previous Element', 'Next Element' messages.
Comment 22 Michael Meeks 2017-07-20 20:27:29 UTC
Nice work Jim ! do you have an initial patch to share on gerrit for comments =)
Comment 23 Yousuf Philips (jay) (retired) 2017-07-20 23:20:00 UTC
Look forward to seeing your commit Jim.

Looking over my mockup again, 'Navigate by' wouldnt be a label in the toolbar, as label's dont appear next to toolbar listboxes and instead it would be the tooltip of the listbox. :D
Comment 24 Jim Raykowski 2017-07-22 00:08:16 UTC
Initial patch ready for comments. 

Yousuf, the tooltip is currently 'Navigation Element'. I would have changed it but didn't see your comment until after uploading patch.
Comment 25 Yousuf Philips (jay) (retired) 2017-07-24 12:49:47 UTC
(In reply to Jim Raykowski from comment #24)
> Yousuf, the tooltip is currently 'Navigation Element'. I would have changed
> it but didn't see your comment until after uploading patch.

'Navigation Element' seems fine to me. :D

Got a link to the commit?
Comment 26 Jim Raykowski 2017-07-25 22:19:10 UTC
The toolbar listbox control and the small navigation popup window now update one another when a navigation item is selected by either method. I'm working on how to update this to the previous patch and will provide a link when this is done. Samuel Mehrbrodt suggested it might be nice to have the icons in the dropdown too. I will be working on this as well as having the previous and next navigate by controls tool tips change with the selected navigate by element.
Comment 27 Yousuf Philips (jay) (retired) 2017-07-26 16:58:45 UTC
(In reply to Jim Raykowski from comment #26)
> The toolbar listbox control and the small navigation popup window now update
> one another when a navigation item is selected by either method. I'm working
> on how to update this to the previous patch and will provide a link when
> this is done.

Sweet.

> Samuel Mehrbrodt suggested it might be nice to have the icons
> in the dropdown too.

I would suggest not doing this as it has very little benefit from a UX perspective and most dropdowns dont have icons. @Heiko: Whats your take?

> I will be working on this as well as having the
> previous and next navigate by controls tool tips change with the selected
> navigate by element.

So how would the modified label be formatted? Would this modification work across multiple windows?
Comment 28 Heiko Tietze 2017-07-26 18:38:02 UTC
(In reply to Yousuf Philips (jay) from comment #27)
> > Samuel Mehrbrodt suggested it might be nice to have the icons
> > in the dropdown too.
> 
> I would suggest not doing this as it has very little benefit from a UX
> perspective and most dropdowns dont have icons. @Heiko: Whats your take?

Yes, context menus do not have icons by default. For menus in general the Microsoft guideline is:

Consider providing menu item icons for:
* The most commonly used menu items.
* Menu items whose icon is standard and well known.
* Menu items whose icon well illustrates what the command does.

Nevertheless I'd like to see how it looks in the wild. Waiting for the upcoming patch since I wasn't able to compile.
Comment 29 Jim Raykowski 2017-07-29 08:02:41 UTC
The dropdown now has icons and the previous and next element controls now change tooltips to indicate what the control will navigate to. For example, if the selected navigate by element is 'Page' the tool tips will be 'Previous Page' and 'Next Page'. Sorry, I am uncertain what 'works across multiple windows' means. I also made a small change so the previous and next controls can be placed in any customizable toolbar. The dropdown can as well.

The recent commit says cannot merge. How to fix this?
Comment 30 Yousuf Philips (jay) (retired) 2017-07-29 14:50:52 UTC
(In reply to Jim Raykowski from comment #29)
> Sorry, I am uncertain what 'works across multiple windows' means.

This means if you have 2 documents open in Writer and the Find toolbar open in both, will the tooltip change work correctly in both windows if the tooltip is changed in one window.
Comment 31 Jim Raykowski 2017-07-29 19:59:09 UTC
(In reply to Yousuf Philips (jay) from comment #30)
> (In reply to Jim Raykowski from comment #29)
> > Sorry, I am uncertain what 'works across multiple windows' means.
> 
> This means if you have 2 documents open in Writer and the Find toolbar open
> in both, will the tooltip change work correctly in both windows if the
> tooltip is changed in one window.

Thank you for the explaination. Currently changing the navigate by element in one window does not change the dropdown item or tooltips in other window. If this is correct behavior I will work on implementing.
Comment 32 Jim Raykowski 2017-07-29 20:05:01 UTC
(In reply to Yousuf Philips (jay) from comment #9)
> In bug 89566, i've suggested the reorganization of the navigator
> window/sidebar, which included the inclusion of the navigation window
> buttons into the window/sidebar by having it as a drop down (attachment
> 113625 [details]), so it might be useful to include the same drop down as a
> control in the toolbar.

Is this still desired? If so I am interested to do after this patch.
Comment 33 Yousuf Philips (jay) (retired) 2017-07-30 01:27:35 UTC
(In reply to Jim Raykowski from comment #31)
> Thank you for the explaination. Currently changing the navigate by element
> in one window does not change the dropdown item or tooltips in other window.
> If this is correct behavior I will work on implementing.

Well LO's current behaviour is that if you had two Writer windows open and set a different item the Navigation window, it would change it across multiple windows, so i guess that should likely be the behaviour, as we'd want the set item to be remembered on restarting Writer. @Heiko: What's your take?

(In reply to Jim Raykowski from comment #32)
> Is this still desired? If so I am interested to do after this patch.

Yes this is still desired.
Comment 34 Jim Raykowski 2017-07-30 05:23:40 UTC
(In reply to Yousuf Philips (jay) from comment #33)
> (In reply to Jim Raykowski from comment #31)
> > Thank you for the explaination. Currently changing the navigate by element
> > in one window does not change the dropdown item or tooltips in other window.
> > If this is correct behavior I will work on implementing.
> 
> Well LO's current behaviour is that if you had two Writer windows open and
> set a different item the Navigation window, it would change it across
> multiple windows, so i guess that should likely be the behaviour, as we'd
> want the set item to be remembered on restarting Writer. @Heiko: What's your
> take?
> 

Yousuf I again looked into the navigation element changing across windows and indeed it does behave as you have said. When I tested this at first I did not click over to the other window so it appeared this was not the behavior. Only after clicking on the other window the dropdown and popup updated to the selected navigate by element of the window they were changed in.
Comment 35 Jim Raykowski 2017-08-04 01:39:49 UTC
Ok I've experienced some setback due to changes made to SwResId which were included in the dev master just after I pulled the master which my work was based on. It confused me when things were working locally and Jenkins passed the commit and Samual commented that it looked good but Heiko's build failed. So I now have a master that is only two days old and am close to being able to commit again. Also I found and have fixed a bug introduced when the SwResId was changed that makes the previous and next tooltips for the popup and sidebar controls not correctly display a tooltip. Specifically SwScrollNaviPopup::GetToolTip const char* id=STR_IMGBTN_ARY[nResId] I believe needs to be [nResId-NID_START] for the index. Along that line I have made the scrolltoprevious and scrolltonext control tooltips to use the same as the popup so instead of 'Previous Repeat Search' the scrolltoprevious toolbar control will show 'Continue Search Backwards'
Comment 36 Jim Raykowski 2017-08-04 23:22:45 UTC
Here is the new patch ready for comments.

https://gerrit.libreoffice.org/#/c/40776/1
Comment 37 Commit Notification 2017-08-10 06:44:42 UTC
James Raykowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e8208057d098f961a62efa5318a80b0d3372d2a

tdf#79167 Change search type through a drop down control

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 38 Samuel Mehrbrodt (allotropia) 2017-08-10 06:47:30 UTC
So this is fixed now, thanks Jim!

To clean the Navigator up we should consider dropping this navigation stuff from the Navigator as we have a good working solution in the findbar now.

The only thing that is missing is that you can enter a number directly. Although we have the "Go to page" feature for that. Just not for other elements.

Thoughts?
Comment 39 Heiko Tietze 2017-09-18 13:50:13 UTC
*** Bug 112437 has been marked as a duplicate of this bug. ***
Comment 40 Harald Koester 2018-01-30 22:07:31 UTC
I checked the new drop down menu (Ver. 6.0.0.3, Win 10). 2 Comments:

(1) If you search for a previous or next item and the item does not exist, there is no error message. I would expect a message similar, if a search string is not found ("Search key not found"). Write new bug report?

(2) If you perform a normal find text operation, the object type of the new drop down menu is switched to "Repeat search". This is a bit awkward, if you always have to switch back to the original object type. To my opinion the item "Repeat search" can be omitted in the new menu, because all searches can be done with the drop down menu for searches.
Comment 41 sophie 2018-01-31 16:15:30 UTC
(In reply to Harald Koester from comment #40)
> I checked the new drop down menu (Ver. 6.0.0.3, Win 10). 2 Comments:
> 
> (1) If you search for a previous or next item and the item does not exist,
> there is no error message. I would expect a message similar, if a search
> string is not found ("Search key not found"). Write new bug report?

As this is a navigation drop down, I wouldn't expect an error message, but that could be an enhancement :)
> 
> (2) If you perform a normal find text operation, the object type of the new
> drop down menu is switched to "Repeat search". This is a bit awkward, if you
> always have to switch back to the original object type. To my opinion the
> item "Repeat search" can be omitted in the new menu, because all searches
> can be done with the drop down menu for searches.
Agreed there, I wouldn't expect the 'navigate by' to be changed, could you also open a bug for that? Thanks! Sophie
Comment 42 Harald Koester 2018-02-10 22:56:40 UTC
(In reply to sophie from comment #41)
> (In reply to Harald Koester from comment #40)
> > I checked the new drop down menu (Ver. 6.0.0.3, Win 10). 2 Comments:
> > 
> > (1) If you search for a previous or next item and the item does not exist,
> > there is no error message. I would expect a message similar, if a search
> > string is not found ("Search key not found"). Write new bug report?
> 
> As this is a navigation drop down, I wouldn't expect an error message, but
> that could be an enhancement :)

New bug report created: Bug 115600.

> > 
> > (2) If you perform a normal find text operation, the object type of the new
> > drop down menu is switched to "Repeat search". This is a bit awkward, if you
> > always have to switch back to the original object type. To my opinion the
> > item "Repeat search" can be omitted in the new menu, because all searches
> > can be done with the drop down menu for searches.
> Agreed there, I wouldn't expect the 'navigate by' to be changed, could you
> also open a bug for that? Thanks! Sophie

New bug report created: Bug 115620.
Comment 43 Xisco Faulí 2018-02-20 10:24:04 UTC
*** Bug 96483 has been marked as a duplicate of this bug. ***