was looking at bug 156311 and noticed the Calc Tab bar controls (Tabbar.cxx) are not responding to mouse click for moving between sheets, at least on Windows builds. Those are popup labeled in .UI as "Scroll to first sheet", "Scroll to previous sheet", "Scroll to next sheet", "Scroll to last sheet". The "Add new sheet" button works as expected. =-testing-= Version: 7.6.0.1 (X86_64) / LibreOffice Community Build ID: 776eaf34564cbf3f034a0ba1fd1d5c32ff9ccf1c CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9fc0b2b9b96d87eb642a3b29e9dcb5d6273265eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
IIRC, the "arrow" icons / on-screen controls to move to the next or prior worksheet, and to move the first / last worksheet, never worked in LO (on MS Windows at least). If this is kept for MS Windows only, I would suggest setting "inherited from OOo". Others would need to test for other OSes in older versions.
For me they appear disabled (greyed out) even when we have multiple sheets. Looks like a but to me. I'm on KDE (Linux) Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 4:7.5.4-0ubuntu0.23.04.1 Calc: threaded
(In reply to ady from comment #1) > IIRC, the "arrow" icons / on-screen controls to move to the next or prior > worksheet, and to move the first / last worksheet, never worked in LO (on MS > Windows at least). > > If this is kept for MS Windows only, I would suggest setting "inherited from > OOo". Others would need to test for other OSes in older versions. You may be right, just checked against on hand Windows 10 installs of: 7.3.7, 6.4.7, and 5.4.7 and the Tabbar.cxx button controls are non-functional when opening a multi-sheet test document. Simply hadn't noticed. But I think they worked at some point before Tomaž split them out some time back. Will try to check.
I can confirm it is inherited as present in OOo 3.3 on Linux, and still current with a recent master build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b3fdd999f87312447d03915585812b3a5cd48141 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Surprised I can't find duplicates...
The Summary reads "Tabbar sheet controls (First, Next, Previous, Last) not working / greyed out". I cannot confirm it — checked on Windows with many LO versions, starting from 3.3.0.4. The navigation buttons are disabled (grayed out) only under certain conditions. The buttons allow the user to move the sheet tabs (respectively: first, previous, next, last) into view. AFAICT, Excel applies the same logic. (In reply to Stéphane Guillou (stragu) from comment #4) > > Surprised I can't find duplicates... Perhaps due to comments in other bug reports e.g.: Bug 89265, Bug 93439, Bug 94439 or Bug 91514. ---------- Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (pl_PL); UI: en-US Calc: threaded
(In reply to nutka from comment #5) > The Summary reads "Tabbar sheet controls (First, Next, Previous, Last) not > working / greyed out". I cannot confirm it — checked on Windows with many LO > versions, starting from 3.3.0.4. > > The navigation buttons are disabled (grayed out) only under certain > conditions. > > The buttons allow the user to move the sheet tabs (respectively: first, > previous, next, last) into view. AFAICT, Excel applies the same logic. > Oh /me embarrassed. Going the change the scope of this to an enhancement of the Sheet-Tabs-Bar rather than just => NAB for buttons that do work. Just realized my OP is just wrong as the Sheet "Tabs" Navigation bar is only active when the number of Sheet tabs exceeds the LO frame width. When all sheet tabs are in view the movement button have no action. That is to say the First, Previous, Next, and Last buttons on the Sheet Tab are *always* visible and show tool tips "scroll to..." which suggests they can be used to navigate from sheet to sheet. But in fact they only reposition the bar full of Sheet tabs--and have that function all the way back to OOo. No impact on the sheet with cursor focus, so not really movement controls. So, enhancement would be to make these prominent buttons actually able to move cursor focus between the sheets. Imagine they'll need UNO created to support Keyboard assignment/customization. Enable focus movements by default, but probably would need ability to disable should a user find it too uncomfortable to their work flow. @quikee, erack - appreciate your dev perspective on if this overloading would cause issues.
These worksheet tabs buttons always worked in the same way, at least under MS Windows (while the documentation could be slightly improved). If you have, say, 5 non-hidden worksheets, then the buttons are grayed out. If you have, say, 50 non-hidden worksheets (so part of the tabs are not seen on screen, simply because of the available horizontal available space), then the these buttons are actionable. STR: 0. We start from the first-and-only default empty blank worksheet, "Sheet1". 1. Press the "+" worksheet tabs button in order to add a new worksheet. 2. Repeat step 1 several times, until the whole width of the current Calc window is occupied with worksheet tabs (but not more than that). The buttons are still grayed out. 3. Repeat step 1 one more time, so the whole set of worksheet tabs does not fit within the horizontal width of the (Calc) window. 3.1. The first tab (e.g. "Sheet1") will not be seen (which is fine). The left-most worksheet tab that is seen on screen will be "Sheet2". The worksheet navigation buttons are no-longer grayed out, so they can be used now. IOW, the buttons do not change the focus of the "active" worksheet (which is what many users intuitively interpret from these buttons), but rather move/slide (horizontally) the worksheet tab bar itself.
Created attachment 197120 [details] Screenshot Excel We discussed the topic in the design meeting. As mentioned before, the controls are kind of tab overflow scrolling mechanism. It might be very useful and needed for people who deal with a lot of tabs and need to know whether the document contains a certain tab without changing the focus. For the average user this sounds a bit far-fetched, and our implementation is also easy to misunderstand. Excel limits the control to left/right, with ctrl+click for the first/last tab, and right click to see all sheets. We can do the same, or rather just drop the first/last interaction. And the label could be more informative like "Scroll to previous tab when overflowing" (using tab instead of sheet).
Code pointer: svtools/source/control/tabbar.cxx
(In reply to Heiko Tietze from comment #8) > > We discussed the topic in the design meeting. > @Heiko, * Just to clarify, the UX recommendation is a => WF of summary. No cell focus movement based on Tab bar positioning. With some improved label/tooltip--and possible dropping the 'Scroll to [first|last] sheet' button actions (leaving just a keyboard shortcut). Otherwise no change to legacy sheet tab bar behavior. Could you adjust the summary to reflect what is now an easyHack suggestion.
(In reply to V Stuart Foote from comment #10) > possible dropping the 'Scroll to [first|last] sheet' button actions (leaving > just a keyboard shortcut). We already have (or suffered) the change of worksheet tabs to cycle from the last to the first, instead of introducing an advance option to change the classic behavior. The icons in question here are already misunderstood by more than one user. If you remove the first/last icons, it would make the action less intuitive than before, and users that used to take advantage of the first/last positions (when they were not automatically cycling) will be even more confused (and disappointed). IMHO, documentation and tool-tips for these icons actions/effects/usage should be much improved, before thinking of removing any part of these UI icons. Even if you remove the first/last worksheet icons, they should still be available for customization, so users that still want them can still use them.
(In reply to ady from comment #11) > Even if you remove the first/last worksheet icons, they should still be > available for customization, so users that still want them can still use > them. These button are not UNO commands and wont show up in the customization. How about a context menu, inspired by MSO's right-click-go-to hack?
(In reply to Heiko Tietze from comment #12) > How about a context menu, inspired by MSO's right-click-go-to hack? As explained in detail in comment 11, discover-ability (and clear understanding of effects and usage). Without those initial UX issues, this ticket would not even exist. ATM, I see very little gain (or rather none at all) from deleting the first/last buttons/icons from the UI.