Current master against 7.2.0 the Sidebar Deck widths are finally responding consistently to width adjustments. One exception is on the Navigator deck. The 'Go to Page' Spin box selector will not resize narrower and is holding the deck further open than it needs to be.
Impact of inability to reduce the Spinbox's width, becomes more obvious at higher WDM scaling, e.g. 250% -- if it can be made to scale better will improve the UX.
Created attachment 171259 [details] The 'Go to Page' spin box on Navigator SB deck at WDM 250% scaling, wasted space The 'Go to Page' spin box at 250% WDM scaling, the red hatching is wasted space that holds the deck open too wide when resized. @Heiko, can width assigned to Spinboxes be reduced?
(In reply to V Stuart Foote from comment #2) > @Heiko, can width assigned to Spinboxes be reduced? Don't see the with of this control in navigatorpanel.ui being forced to a certain number. The spinedit's constraints probably come from the OS/DE. The spinedit is displaced in cases when the dropdown shows something else but page. Perhaps we move it away- or provide the input at the statusbar rather than the Navigator.
(In reply to Heiko Tietze from comment #3) > ... Perhaps we move it away- or provide the input at the statusbar > rather than the Navigator. Well I'd hate to strip it out of the Navigator, it sort of belongs there. Just seems like we should assign it a size to hold 1-999 pages (3-digits), if possible, and be done with it. Thought the inability for the widget to shrink in X-direction seems weird.
It is set in the code to hold 3 digits but seems to be only honored by gtk3. https://opengrok.libreoffice.org/xref/core/sw/source/uibase/utlui/navipi.cxx?r=2633d5f9#535
And saving one character space is not much...
(In reply to Heiko Tietze from comment #6) > And saving one character space is not much... Except that at higher UI scaling, at least for the WDM of Windows os/DE, the "extra" spaces are being amplified into excessive width.
*** Bug 142082 has been marked as a duplicate of this bug. ***
Created attachment 171633 [details] Navigator clip from dupe bug 142082
(In reply to Jim Raykowski from comment #5) > It is set in the code to hold 3 digits but seems to be only honored by gtk3. > > https://opengrok.libreoffice.org/xref/core/sw/source/uibase/utlui/navipi. > cxx?r=2633d5f9#535 (In reply to Heiko Tietze from comment #6) > And saving one character space is not much... Would it be too weird to move the 'Go to Page' spinbox widget onto its own row in the Navigator Header? Or maybe even onto the Deck label bar since it is only by 'Page' movments, regardless of 'Navigate by' mode set.
(In reply to V Stuart Foote from comment #10) > Would it be too weird to move the 'Go to Page' spinbox widget onto its own > row in the Navigator Header? The UI is totally overloaded and against a11y guidelines right now. So no, it will not make it worse. But definitely also not better.
We discussed the topic in the design meeting. The control does not pick up the current page number, neither what is entered at the "go to page" dialog or what is done with the next/previous page control next to it. So it would be better to remove the buggy control. If this is not convincing then we should move it to the next row rather than doing nothing. In this case it's an easyhack at sw/uiconfig/swriter/ui/navigatorpanel.ui.
*** Bug 159711 has been marked as a duplicate of this bug. ***
Would kind of like Jim R.'s thought on impace/design of stripping it out, vs dropping onto a new line, vs removing its spinbox widget in favor of a simple value field (displaying the current page with focus). Can't remember how "integrated" the Navigator 'Go to page' instance is with the Find bar, or current work on the SB Quick find. @Jim?
s/impace/impact/
Created attachment 192624 [details] Navigate by Page vertical go to page control demo Possibly what is shown in this demo would be a compromise to the complete removal of the go to page control.
(In reply to Jim Raykowski from comment #16) > Created attachment 192624 [details] > Navigate by Page vertical go to page control demo > > Possibly what is shown in this demo would be a compromise to the complete > removal of the go to page control. @Jim, * Looks promising! I like the addition of the current page in the field, that's been missing. What happens if expert config 'minimumwidth' is set false? Would the Navigate by "Page" listbox narrow first, or the current page field and spin box buttons? Meaning, for the minimuwidth collapse are we restricted only to the right edge of the widgets? Or can we take width from elements across the control?
Created attachment 192625 [details] MinimuWidth set false demo (In reply to V Stuart Foote from comment #17) > What happens if expert config 'minimumwidth' is set false? Would the > Navigate by "Page" listbox narrow first, or the current page field and spin > box buttons? > > Meaning, for the minimuwidth collapse are we restricted only to the right > edge of the widgets? Or can we take width from elements across the control? Here's a demo of what currently happens.
(In reply to Jim Raykowski from comment #18) > Created attachment 192625 [details] > MinimuWidth set false demo > > (In reply to V Stuart Foote from comment #17) > > What happens if expert config 'minimumwidth' is set false? Would the > > Navigate by "Page" listbox narrow first, or the current page field and spin > > box buttons? > > > > Meaning, for the minimuwidth collapse are we restricted only to the right > > edge of the widgets? Or can we take width from elements across the control? > Here's a demo of what currently happens. Thanks Jim. Didn't know if the SB framework might allow a more nuanced collapse. But the new by Page control is certainly no worse than current Go to Page widget.
(In reply to Jim Raykowski from comment #16) > Possibly what is shown in this demo would be a compromise to the complete > removal of the go to page control. -1 from my side to the vertical spin box.
(In reply to Heiko Tietze from comment #20) > (In reply to Jim Raykowski from comment #16) > > Possibly what is shown in this demo would be a compromise to the complete > > removal of the go to page control. > -1 from my side to the vertical spin box. Bcz it is 3 .UI blocks high? Possible alternative? In the Navigate by Page mode as Jim suggests, could the "GoToPage" down up buttons be over loaded onto the "navigate by" down up buttons? So just the "current page" field would remain on the Navigate .UI line? <Enter> would fire a typed value for 'go to page' in all navigate modes. But the navigate by buttons would advance or reverse according to the active navigate mode as now. And *only* when in Navigate by Page would they actively advance or reverse the current page field? Effectively eliminate the separate 'Go to Page' widget's down up buttons?
(In reply to Heiko Tietze from comment #20) > Bcz it is 3 .UI blocks high? I am also quite taken a back by that (but not by the very idea of a vertical spin box on the side if and when this is crucial for saving space).
Created attachment 192648 [details] Comparison of gen, qt5, and gtk3 Taking 3 rows to display the spin control when it is set vertical only happens for Gtk3. The other VCL backends I can test only take 1 row.
Created attachment 192650 [details] Navigate By Page Gtk3 horizontal go to page control demo Here is a demo using gtk3 VCL backend that shows the go to page control set in horizontal mode. The demo shows that the Navigator deck takes slightly less width than the Styles deck. Maybe showing an additional row for the Go To Page control when the Navigate By control is set to Page would be better.
Created attachment 192652 [details] Go to Page control on separate row demo
Why do you need access to the function in the sidebar deck? There are plenty of alternatives. And I doubt it's used much anyway. Simplicity first; the less controls on the UI the easier to use.
(In reply to Heiko Tietze from comment #26) > Why do you need access to the function in the sidebar deck? There are plenty > of alternatives. And I doubt it's used much anyway. > > Simplicity first; the less controls on the UI the easier to use. Yes the 'Go to Page' is available as a pop-up dialog, but the instance integrated into the Navigator deck remains a prominent placement. Seems it would be odd to not provide a go to page function in a SB deck devoted to document content navigation? Still asking about my suggestion to eliminate the separate page advance/reverse buttons with the widget as in comment 21
(In reply to Jim Raykowski from comment #23) > Taking 3 rows to display the spin control when it is set vertical only > happens for Gtk3. The other VCL backends I can test only take 1 row. I like that 1-row spin control on the other backends. (I don't like how there's a gap on the left of the drop-down list box, but that's not the important point here.) Unfortunately, gtk3 is the default in the DEBs and RPMs we distribute; and even if it weren't, it's still an important VCL. Heiko, if something could be done for the GTK 3 control, would the design be ok with you? (In reply to Heiko Tietze from comment #26) > Why do you need access to the function in the sidebar deck? Because it's the navigator, and navigating by page number seems like an important aspect of document navigation. > There are plenty of alternatives. And I doubt it's used much anyway. Well, we could probably make that argument about other features of the navigator, like navigation among Headings. But I'll say in fairness that I never use the navigator to move between pages. > Simplicity first; the less controls on the UI the easier to use. That extremist approach has been applied to ruinous effect in GNOME. It is not true that the less controls a UI has the easier it is to use; rather, that a multitude of controls increase the difficulty of use beyond their potential benefit; and those are two different statemes. Simplicity, should not come first, before anything else; rather, we should temper our UI design with the principles of expressiveness, feature accessibility, simplicity, consistency and other considerations, all together.
Created attachment 192676 [details] Go to Page button approach Not thinking this one is going to be well received. Just throwing things out for consideration. Demo of Stuart's suggestion in comment 21 in progress.
Created attachment 192677 [details] Comment 21 go to page entry control demo
Created attachment 192678 [details] Reduced Navigate By combo box width demo Here is a demo that uses a 33% reduced width Navigate By drop down with the go to entry box approach. This reduced width could be used for the spin entry approach as well.
(In reply to V Stuart Foote from comment #27) > Yes the 'Go to Page' is available as a pop-up dialog, but the instance > integrated into the Navigator deck remains a prominent placement. (In reply to Eyal Rozenberg from comment #28) > Because it's the navigator, and navigating by page number seems like an > important aspect of document navigation. Not against Next/Prev but what workflow requires you to go to some exact page number? It's a rhetorical question, and for sure you can oppose the KISS argument easily (but not generally valid). (In reply to V Stuart Foote from comment #27) > Still asking about my suggestion to eliminate the separate page > advance/reverse buttons with the widget as in comment 21 Meaning no prev/next buttons in case of Pages but the spinedit. Maybe. (In reply to Jim Raykowski from comment #29) > Created attachment 192676 [details] > Go to Page button approach Would be a compromise. I dislike the demos in #30 and #31 as it turns the spinedit into simple edit controls. We need to ensure min/max, have to take care of proper alignment with the current page, deal with interactions (enter a number, validate, apply on exit, etc.). Mind to try Stuart's proposal to replace prev/next with the spinedit?
Created attachment 192699 [details] Demo of reduced width Navigate By drop down with Go to Page spin control replacing previous and next buttons when Page is selected (In reply to Heiko Tietze from comment #32) > Mind to try Stuart's proposal to replace prev/next with the spinedit? This demo is close to the same as what is shown in attachment 192650 [details] but has a reduced width Navigate By drop down and a bit of space between the drop down and spin edit controls.
Created attachment 192707 [details] Go to page control page in view tracking demo Same layout as show in attachment 192699 [details] with added page in view tracking.
(In reply to Jim Raykowski from comment #34) > Created attachment 192707 [details] > Go to page control page in view tracking demo LGTM!
(In reply to Jim Raykowski from comment #34) > Created attachment 192707 [details] > Go to page control page in view tracking demo > > Same layout as show in attachment 192699 [details] with added page in view > tracking. +1, this view tracking is a great enhancement to Navigator! Do the reduced width listbox and tracked page# field scale well with the os/DE? And will still show acceptable behavior with 'minimumwidth' and the -/+ are hidden?
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/139199ee9c09d25624191132adbe4fd29365eb7a tdf#141728 Revamp sw navigator go to page spin control It will be available in 24.8.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 V Stuart Foote from comment #36) > Do the reduced width listbox and tracked page# field scale well with the > os/DE? And will still show acceptable behavior with 'minimumwidth' and the > -/+ are hidden? Please let me know if you find issues with these :)
(In reply to Heiko Tietze from comment #35) > (In reply to Jim Raykowski from comment #34) > > Created attachment 192707 [details] > > Go to page control page in view tracking demo > LGTM! So, if I understand correctly, the change here is dropping the next/prev buttons in favor of using the spin control -/+ buttons with view tracking. That seems fine to me as well. But I'll again say that the drop-down list box seems indented a little leftwards of the left edge of the sidebar, relative to the second and third rows of controls. Jim, is this intentional? I think you could just let it extend a bit further to the left (i.e. not move it, extend it).
(In reply to Eyal Rozenberg from comment #39) > But I'll again say that the drop-down list box seems indented a little > leftwards of the left edge of the sidebar, relative to the second and third > rows of controls. Jim, is this intentional? I think you could just let it > extend a bit further to the left (i.e. not move it, extend it). viewing Jim's attachment 192707 [details] Yes it is indented slightly, but isn't that just the .UI packing for the Navigator's main Toolbox? It is much less pronounced on the win backend, and the nav mode listbox is aligned to left edge as set by the ellipsis of the Deck title bar.
Yes there is work to be done to tidy up the layout of the first row of controls. In addition, there is the Content Navigation View toggle button that maybe should be greyed out when nothing is selected in the content tree. I did a followup patch to add a bit of space between the 'Navigate By' and the new go to page spin control which currently has no space between them for non gtk VCL backends. https://gerrit.libreoffice.org/c/core/+/163799 Perhaps a separate bug report should be made for these other issues or just include the fixes in with the above patch?
(In reply to Jim Raykowski from comment #41) > Perhaps a separate bug report should be made for these other issues or just > include the fixes in with the above patch? Tidy up the layout - with the above patch. Content navigation view toggle button - not quite sure what you mean, but if you added it with the patch for this bug, then IMHO you can include that too. But if it existed before, then I'd say separate bug.
Created attachment 192736 [details] Content Navigation View button (In reply to Eyal Rozenberg from comment #42) > Content navigation view toggle button - not quite sure what you mean
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/61f34fde10e6f5cad7d23826b4dad716fef43e6c tdf#141728 follow up: provide a bit of space between controls It will be available in 24.8.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 Eyal Rozenberg from comment #42) > too. But if it existed before, then I'd say separate bug. The issue with the first row indent seems to have existed before. It is caused by the way the Toggle Master View button is hid. I have a patch ready, just need a ticket to file it under.
(In reply to Jim Raykowski from comment #45) > (In reply to Eyal Rozenberg from comment #42) > > too. But if it existed before, then I'd say separate bug. > The issue with the first row indent seems to have existed before. It is > caused by the way the Toggle Master View button is hid. I have a patch > ready, just need a ticket to file it under. @Jim, opened as bug 159875. Assigned to you...
Testing with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 74185b8edf7f046a3372319da86a1d8ca0024c87 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded The spinbox for the Go to Page field feels comfortable to use, though reverses the movement sense of the previous Page navigation arrows (old down for next, up for previous)--but obvious feedback with the page tracking now in place. And packing of top row of buttons for bug 159875 is also good. However, still seem to have an issue with the number of digits that the go to page box will hold (as in comment 5). With expert config 'minimumwidth' set false, dragging it narrower on Windows it holds space open for 11 digits! ~75px in UI before the spinner starts to be hidden. 3 or maybe 4 digits seems appropriate. Reopen, or a new BZ issue?
Created attachment 192818 [details] Demo showing static go to page control width (In reply to V Stuart Foote from comment #47) > The spinbox for the Go to Page field feels comfortable to use, though > reverses the movement sense of the previous Page navigation arrows I noticed this also. Unfortunately there is not an easy one liner to make the arrows switch behavior. > However, still seem to have an issue with the number of digits that the go > to page box will hold (as in comment 5). With expert config 'minimumwidth' > set false, dragging it narrower on Windows it holds space open for 11 > digits! ~75px in UI before the spinner starts to be hidden. 3 or maybe 4 > digits seems appropriate. How about what is shown in the attached demo? > Reopen, or a new BZ issue? follow up patch: https://gerrit.libreoffice.org/c/core/+/164003
(In reply to Jim Raykowski from comment #48) > Created attachment 192818 [details] > Demo showing static go to page control width >... > How about what is shown in the attached demo? > Yes, it looks like dropping the horizontal expand for the spinbox is what was needed.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f34292a105fd1660fbef5f6811ea37ffdfff6c50 tdf#141728 follow up: don't expand spin control when sidebar is resized It will be available in 24.8.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.
Testing the 20240228 nightly build dropping the horizontal expand for the Go-to-page spin box has reduced the toolbox controls width on the Navigator deck. It retains an ~5 digit field width, and no longer holds the deck too wide. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5234ef71c7459506236d4d0dfe7beb5f00d8cc41 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #51) Also, created a 10,015 page test document. <Ctrl>+G 'Go to page' pop-up dialog and the toolbox on the Navigator have no issues at the 9,999 boundary. Both flavors of the spinbox seem functional for page movements! While the SB deck behaves when os/DE is scaled--with no issue at 350%.