Bug 141728 - Navigator SB deck, 'Go to Page' Spin box is holding deck width too wide
Summary: Navigator SB deck, 'Go to Page' Spin box is holding deck width too wide
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Jim Raykowski
URL:
Whiteboard: target:24.8.0
Keywords:
: 142082 159711 (view as bug list)
Depends on:
Blocks: Navigator Sidebar-UI-UX Navigate-By
  Show dependency treegraph
 
Reported: 2021-04-17 17:35 UTC by V Stuart Foote
Modified: 2024-08-08 23:30 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
The 'Go to Page' spin box on Navigator SB deck at WDM 250% scaling, wasted space (37.99 KB, image/png)
2021-04-17 17:54 UTC, V Stuart Foote
Details
Navigator clip from dupe bug 142082 (2.87 KB, image/png)
2021-05-04 15:22 UTC, V Stuart Foote
Details
Navigate by Page vertical go to page control demo (1.26 MB, video/x-matroska)
2024-02-18 19:06 UTC, Jim Raykowski
Details
MinimuWidth set false demo (323.60 KB, video/x-matroska)
2024-02-18 19:45 UTC, Jim Raykowski
Details
Comparison of gen, qt5, and gtk3 (69.52 KB, image/png)
2024-02-20 03:36 UTC, Jim Raykowski
Details
Navigate By Page Gtk3 horizontal go to page control demo (608.77 KB, video/x-matroska)
2024-02-20 06:37 UTC, Jim Raykowski
Details
Go to Page control on separate row demo (695.18 KB, video/x-matroska)
2024-02-20 07:34 UTC, Jim Raykowski
Details
Go to Page button approach (299.67 KB, video/x-matroska)
2024-02-21 03:04 UTC, Jim Raykowski
Details
Comment 21 go to page entry control demo (1.39 MB, video/x-matroska)
2024-02-21 03:09 UTC, Jim Raykowski
Details
Reduced Navigate By combo box width demo (613.34 KB, video/x-matroska)
2024-02-21 05:59 UTC, Jim Raykowski
Details
Demo of reduced width Navigate By drop down with Go to Page spin control replacing previous and next buttons when Page is selected (1.93 MB, video/x-matroska)
2024-02-21 23:43 UTC, Jim Raykowski
Details
Go to page control page in view tracking demo (2.97 MB, video/x-matroska)
2024-02-22 07:36 UTC, Jim Raykowski
Details
Content Navigation View button (10.86 KB, image/png)
2024-02-23 23:51 UTC, Jim Raykowski
Details
Demo showing static go to page control width (1.32 MB, video/webm)
2024-02-27 08:33 UTC, Jim Raykowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2021-04-17 17:35:49 UTC
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.
Comment 1 V Stuart Foote 2021-04-17 17:41:23 UTC
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.
Comment 2 V Stuart Foote 2021-04-17 17:54:44 UTC
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?
Comment 3 Heiko Tietze 2021-04-19 15:41:59 UTC
(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.
Comment 4 V Stuart Foote 2021-04-19 15:55:22 UTC
(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.
Comment 5 Jim Raykowski 2021-04-20 07:58:38 UTC
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
Comment 6 Heiko Tietze 2021-04-20 08:05:31 UTC
And saving one character space is not much...
Comment 7 V Stuart Foote 2021-04-20 15:45:05 UTC
(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.
Comment 8 V Stuart Foote 2021-05-04 15:18:23 UTC
*** Bug 142082 has been marked as a duplicate of this bug. ***
Comment 9 V Stuart Foote 2021-05-04 15:22:04 UTC
Created attachment 171633 [details]
Navigator clip from dupe bug 142082
Comment 10 V Stuart Foote 2021-05-04 15:31:38 UTC
(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.
Comment 11 Heiko Tietze 2021-05-04 17:03:18 UTC
(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.
Comment 12 Heiko Tietze 2022-02-24 14:43:40 UTC
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.
Comment 13 V Stuart Foote 2024-02-14 14:52:33 UTC
*** Bug 159711 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2024-02-16 15:16:58 UTC
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?
Comment 15 V Stuart Foote 2024-02-16 15:18:03 UTC
s/impace/impact/
Comment 16 Jim Raykowski 2024-02-18 19:06:33 UTC
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.
Comment 17 V Stuart Foote 2024-02-18 19:21:25 UTC
(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?
Comment 18 Jim Raykowski 2024-02-18 19:45:47 UTC
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.
Comment 19 V Stuart Foote 2024-02-18 22:25:57 UTC
(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.
Comment 20 Heiko Tietze 2024-02-19 07:36:26 UTC
(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.
Comment 21 V Stuart Foote 2024-02-19 14:51:05 UTC
(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?
Comment 22 Eyal Rozenberg 2024-02-19 21:28:50 UTC
(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).
Comment 23 Jim Raykowski 2024-02-20 03:36:52 UTC
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.
Comment 24 Jim Raykowski 2024-02-20 06:37:11 UTC
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.
Comment 25 Jim Raykowski 2024-02-20 07:34:58 UTC
Created attachment 192652 [details]
Go to Page control on separate row demo
Comment 26 Heiko Tietze 2024-02-20 07:52:05 UTC
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.
Comment 27 V Stuart Foote 2024-02-20 15:55:54 UTC
(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
Comment 28 Eyal Rozenberg 2024-02-20 23:56:41 UTC
(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.
Comment 29 Jim Raykowski 2024-02-21 03:04:17 UTC
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.
Comment 30 Jim Raykowski 2024-02-21 03:09:48 UTC
Created attachment 192677 [details]
Comment 21 go to page entry control demo
Comment 31 Jim Raykowski 2024-02-21 05:59:16 UTC
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.
Comment 32 Heiko Tietze 2024-02-21 08:24:00 UTC
(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?
Comment 33 Jim Raykowski 2024-02-21 23:43:11 UTC
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.
Comment 34 Jim Raykowski 2024-02-22 07:36:45 UTC
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.
Comment 35 Heiko Tietze 2024-02-22 08:15:54 UTC
(In reply to Jim Raykowski from comment #34)
> Created attachment 192707 [details]
> Go to page control page in view tracking demo
LGTM!
Comment 36 V Stuart Foote 2024-02-22 14:01:07 UTC
(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?
Comment 37 Commit Notification 2024-02-22 18:25:26 UTC
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.
Comment 38 Jim Raykowski 2024-02-22 18:32:58 UTC
(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 :)
Comment 39 Eyal Rozenberg 2024-02-23 14:10:42 UTC
(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).
Comment 40 V Stuart Foote 2024-02-23 15:44:57 UTC
(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.
Comment 41 Jim Raykowski 2024-02-23 21:59:08 UTC
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?
Comment 42 Eyal Rozenberg 2024-02-23 22:56:43 UTC
(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.
Comment 43 Jim Raykowski 2024-02-23 23:51:26 UTC
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
Comment 44 Commit Notification 2024-02-24 20:54:21 UTC
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.
Comment 45 Jim Raykowski 2024-02-24 21:41:07 UTC
(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.
Comment 46 V Stuart Foote 2024-02-25 00:33:00 UTC
(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...
Comment 47 V Stuart Foote 2024-02-26 14:11:42 UTC
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?
Comment 48 Jim Raykowski 2024-02-27 08:33:37 UTC
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
Comment 49 V Stuart Foote 2024-02-27 12:31:22 UTC
(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.
Comment 50 Commit Notification 2024-02-27 14:05:14 UTC
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.
Comment 51 V Stuart Foote 2024-02-28 16:42:02 UTC
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
Comment 52 V Stuart Foote 2024-02-28 17:03:08 UTC
(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%.