Vertical-tab dialogs should generally not have so many tabs with so little dialog height, that tabs exceed the dialog height and go out of view. But - when that _does_ happen for some reason - we should at least make sure the tabs are scrollable by using the mouse wheel when hovering over tha tabs area. And - that is not the case with: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d9eac4f95649f04e1ddbe5026d8bb323c1fc58d8 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
Mouse-wheeling works for me (Linux and Windows) but we need some overflow mechanism including an indicator as done natively under gtk3. I suggest to change the summary.
(In reply to Heiko Tietze from comment #1) > Mouse-wheeling works for me (Linux and Windows) but we need some overflow > mechanism including an indicator as done natively under gtk3. I suggest to > change the summary. With recent changes to the 26.2 nightlies, which dialog has vertical tabs exceeding the dialog height? To test whether mousewheel scrolling now works?
Drawing/Presentation style in Draw/Impress are the largest with 16 tabs.
(In reply to Heiko Tietze from comment #3) > Drawing/Presentation style in Draw/Impress are the largest with 16 tabs. Ok, in Draw, with a new empty dragin, when I edit a Drawing Style, the dialog has vertical tabs exceeding the height. I see the top and bottom arrows. But - mousewheel scrolling (which works for me elsewhere) does not work for this dialog. Neither when the cursor is within the relevant dialog, nor when it's outside. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c9c96987c31efe7108d0588ef097e952d623238c CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: CL threaded
Can't check with VCL qt5, because there the dialog is just high enough for all the tabs.
Gtk3 has dedicated overflow button that allow to scroll through the list.
(In reply to Heiko Tietze from comment #6) > Gtk3 has dedicated overflow button that allow to scroll through the list. That should exist with other VCLs as well. I naturally meant that mouse-wheel scrolling must be possible in _addition_ to a visible button.
(In reply to Heiko Tietze from comment #1) > I suggest to change the summary.
*** Bug 167955 has been marked as a duplicate of this bug. ***
I accidentally noticed that in such cases, you can right-click the tabs list to have a compact menu that lets you directly join to any of the off-screen scrolled tabs. That said, 16 tabs seems like an unusually high amount of pages, vs 5-10 tabs… In extreme cases like that, maybe you would be better served by using the same widget as the global Options' dialog (the vertically scrollable treeview/listview), which is more compact and (by nature of being scrollable) does not have such limitations?
(In reply to Jeff Fortin Tam from comment #10) > I accidentally noticed that in such cases, you can right-click the tabs list > to have a compact menu that lets you directly join to any of the off-screen > scrolled tabs. Yes, but that's even more confusing, since it's not visually obvious that the elements on this menu are the dialog tabs; you have to basically believe it. Plus, when you make a selection that way, the set of visible tabs change, and now you have no idea where you are, it's just a bunch of unrecognized tabs everywhere. > That said, 16 tabs seems like an unusually high amount of pages, vs 5-10 > tabs… Remember the vertical tabs made an appearance in the first place because of the dialogs with lots of tabs, where 2 and especially 3 lines of top tab-headers felt excessive and confusing. > In extreme cases like that, maybe you would be better served > by using the > same widget as the global Options' dialog (the vertically scrollable > treeview/listview), which is more compact and (by nature of being > scrollable) does not have such limitations? It's not an extreme case, and it's not about myself but about all of our users. Editing a paragraph style or opening other dialogs with many tabs is not an extreme case. Having said that - yes, that is a possible workaround here. But in 26.2 we're supposed to have icons next to tab names... Also, I seem to be seeing different behavior with newer nightlies, e.g. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ed45cdaef3d2807d0b9d6a4c08da375fc72024a6 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US is it just me or has a change been introduced to avoid the overflow?