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.
Asking for UX advice on this one. Thanks for reporting :)
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
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
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
Hi Samuel, It seems that your change on navigation toolbar has some weird side effect. Please could you have a look ? Best regards. JBF
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).
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
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.
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.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
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.
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.
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.
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.
(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.
(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
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.
(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
*** Bug 107352 has been marked as a duplicate of this bug. ***
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.
Nice work Jim ! do you have an initial patch to share on gerrit for comments =)
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
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.
(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?
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.
(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?
(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.
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?
(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.
(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.
(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.
(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.
(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.
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'
Here is the new patch ready for comments. https://gerrit.libreoffice.org/#/c/40776/1
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.
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?
*** Bug 112437 has been marked as a duplicate of this bug. ***
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.
(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
(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.
*** Bug 96483 has been marked as a duplicate of this bug. ***