I had replies over on ask/ pointing out that this was a newly added feature per https://bugs.documentfoundation.org/show_bug.cgi?id=156311.

As such, clearly it's a desired behaviour for some: is it possible to provide a configuration option to disable this - or perhaps rebind the keyboard customisation to a slightly different option?

While I agree with the request to have a keyboard shortcut(s) to go to the first/last worksheet(s), there are several problems with the request, unfortunately.

The first problem to bind a keyboard shortcut to "navigate/go to first worksheet" (and another shortcut for the last worksheet) is that the function is not defined/listed in the Customize list.

I am not sure, but I believe a new UNO command would be needed?


The "second" problem related to this request is that the arrows that should allow to navigate to first/prior/next/last worksheets are not working.

STR:
1. New Calc.
2. Add 3 (empty) worksheets.
3. Try to use the arrow "icons" to navigate to first/prior/next/last worksheets by clicking on any of them.

 > the arrows are all grayed out. AFAIR, these never worked.

There is probably some bug report about this other issue. While this "second" issue is about mouse interaction instead of using the keyboard, these are probably related/connected in some area.

Since this request is a consequence of tdf#156311, I am CC'ing Denis Sorotnik and Heiko.

To clarify, I am not suggesting a new shortcut to go to the first/last sheet - just that the former behaviour of the next/previous shortcuts be made available in some way.
The change made in 24.2 alters long standing things that work:just hold down CTRL-PGDN and you end up at the last sheet. If you really need to get there fast, move to the mouse button. Both options give a certain outcome, while the new reaction of the shortcut is to create uncertainty about which sheet will be active. 

I don't understand any of the architecture, but the buttons in the GUI retain this behaviour, and it existed prior to 24.2, so it's hard to imagine it needs something totally new built.

Regarding exposing something new in the customise list, perhaps a separate entry for "next sheet - wrap at last" might be comprehensible to users?

(In reply to alex from comment #3)
> To clarify, I am not suggesting a new shortcut to go to the first/last sheet
> - just that the former behaviour of the next/previous shortcuts be made
> available in some way.

The request is clear. It would be some advance experimental setting, buried within some not-so-obvious dialogue.

OTOH, since there are no shortcuts available for "go to first/last worksheets", having the possibility to assign a shortcut would be less "advance/experimental".

I was just taking part of your comment 0 and suggesting a possible alternative way to solve the UX problem.

> 
> the buttons in the GUI
> retain this behaviour, and it existed prior to 24.2, so it's hard to imagine
> it needs something totally new built.

For some users, the arrow UI icons to go to first/prior/next/last worksheet are always grayed out, not clickable. You can click on a specific worksheet tab, but not on the arrows. This is a separate bug report, but somewhat related to this request.

> 
> Regarding exposing something new in the customise list, perhaps a separate
> entry for "next sheet - wrap at last" might be comprehensible to users?

The functions I mentioned in my comment 2 would be "to first (work)sheet" and "to last (work)sheet". These do not exist, AFAIK. Whether these would deserve to be added, or to provide whichever alternative to this request, it is for the UX Team and other devs to evaluate.

(In reply to ady from comment #4)
> (In reply to alex from comment #3)
> > To clarify, I am not suggesting a new shortcut to go to the first/last sheet
> > - just that the former behaviour of the next/previous shortcuts be made
> > available in some way.
> 
> The request is clear. It would be some advance experimental setting, buried
> within some not-so-obvious dialogue.
> 
> OTOH, since there are no shortcuts available for "go to first/last
> worksheets", having the possibility to assign a shortcut would be less
> "advance/experimental".
> 
> I was just taking part of your comment 0 and suggesting a possible
> alternative way to solve the UX problem.
> 
> > 
> > the buttons in the GUI
> > retain this behaviour, and it existed prior to 24.2, so it's hard to imagine
> > it needs something totally new built.
> 
> For some users, the arrow UI icons to go to first/prior/next/last worksheet
> are always grayed out, not clickable. You can click on a specific worksheet
> tab, but not on the arrows. This is a separate bug report, but somewhat
> related to this request.
> 
> > 
> > Regarding exposing something new in the customise list, perhaps a separate
> > entry for "next sheet - wrap at last" might be comprehensible to users?
> 
> The functions I mentioned in my comment 2 would be "to first (work)sheet"
> and "to last (work)sheet". These do not exist, AFAIK. Whether these would
> deserve to be added, or to provide whichever alternative to this request, it
> is for the UX Team and other devs to evaluate.

Thanks for the extra info - I realise we're mostly agreeing and hope some improvement can come from the discussion!

My take: introduce UNO commands for first/last sheet and keep the patch unconditional.

(In reply to ady from comment #2)
>  > the arrows are all grayed out. AFAIR, these never worked.

That is tdf#156328.



(In reply to ady from comment #2)
> I am not sure, but I believe a new UNO command would be needed?
> 

(In reply to Heiko Tietze from comment #6)
> My take: introduce UNO commands for first/last sheet and keep the patch
> unconditional.


@Denis, since you very recently solved tdf#156311 that triggered this tdf#160580, maybe you could take a look at this.

*** Bug 162882 has been marked as a duplicate of this bug. ***

*** Bug 162885 has been marked as a duplicate of this bug. ***

The new behavior is aligned with other common UX designs. e.g these applications also wrap around: xfce4-terminal, firefox, GIMP, thunar... I'm sure there are plenty more. I also preferred the previous way This sort of change probably won't be reverted or given an option.

I found this code snippet which selects the 3rd sheet:

  dim document   as object
  dim dispatcher as object
  document   = ThisComponent.CurrentController.Frame
  dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
  dim args1(0) as new com.sun.star.beans.PropertyValue
  args1(0).Name = "Nr"
  args1(0).Value = 3
  dispatcher.executeDispatch(document, ".uno:JumpToTable", "", 0, args1())

If you are motivated enough, you could make a macro triggered with two keyboard shortcuts to do something like this:

  alt-pgup
  if current_sheet != 1
    goto current_sheet-1

  alt-pgdn
    get max_number_of_sheets
    if current_sheet != max_number_of_sheets
      goto current_sheet+1

(In reply to geoff183 from comment #10)
> The new behavior is aligned with other common UX designs. e.g these
> applications also wrap around: xfce4-terminal, firefox, GIMP, thunar... I'm
> sure there are plenty more. I also preferred the previous way This sort of
> change probably won't be reverted or given an option.

Unfortunately, developers might very scarcely use spreadsheet tools (as users). Perhaps we (users) should rather stop using Calc as a spreadsheet tool and we might try using either xfce4-terminal, Firefox, GIMP or Thunar for such purpose(?). Oh, wait, those are not spreadsheet tools. Apparently we should start using those anyway.

Spreadsheets are popular for several reasons, one of them being the flexibility of the relevant tools. Sadly, Calc is being restricted on each iteration, with changes being applied according to some subjective mood ("I like it, and everyone else should too, and everyone will work as I do").

(In reply to geoff183 from comment #10)
> The new behavior is aligned with other common UX designs. e.g these
> applications also wrap around: xfce4-terminal, firefox, GIMP, thunar... I'm
> sure there are plenty more. I also preferred the previous way This sort of
> change probably won't be reverted or given an option.
> 
> I found this code snippet which selects the 3rd sheet:
> 
>   dim document   as object
>   dim dispatcher as object
>   document   = ThisComponent.CurrentController.Frame
>   dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
>   dim args1(0) as new com.sun.star.beans.PropertyValue
>   args1(0).Name = "Nr"
>   args1(0).Value = 3
>   dispatcher.executeDispatch(document, ".uno:JumpToTable", "", 0, args1())
> 
> If you are motivated enough, you could make a macro triggered with two
> keyboard shortcuts to do something like this:
> 
>   alt-pgup
>   if current_sheet != 1
>     goto current_sheet-1
> 
>   alt-pgdn
>     get max_number_of_sheets
>     if current_sheet != max_number_of_sheets
>       goto current_sheet+1

Thanks - it turns out that yes I am motivated enough - it just hadn't occurred to me to fix it that way!

In case it's of use to anybody else at all, here are four macros which can a/ Return the ToNextSheet/ToPreviousSheet to their 'classic' behaviour, and b/ Provide the GotoFirst/GotoLast behaviour that others asked for.
All can be bound to whatever keystrokes are preferred!

REM  *****  BASIC  *****
sub ToNextSheet_classic
	' Select next worksheet but DON'T wrap (ie as prior to v24.2)
	dim document   as object
	dim dispatcher as object
	document   = ThisComponent.CurrentController.Frame
	dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

	dim iSmax as Integer
	dim iSindex as Integer
	iSmax=ThisComponent.Sheets.count - 1
	iSIndex=Thiscomponent.CurrentController.ActiveSheet.RangeAddress.Sheet
	if iSIndex < iSmax then
		dispatcher.executeDispatch(document, ".uno:JumpToNextTable", "", 0, Array())
	end if
end sub
sub ToPreviousSheet_classic
	' Select previous worksheet but DON'T wrap (ie as prior to v24.2)
	dim document   as object
	dim dispatcher as object
	document   = ThisComponent.CurrentController.Frame
	dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

	dim iSindex as Integer
	iSIndex=Thiscomponent.CurrentController.ActiveSheet.RangeAddress.Sheet
	if iSIndex > 0 then
		dispatcher.executeDispatch(document, ".uno:JumpToPrevTable", "", 0, Array())
	end if
end sub
sub ToFirstSheet
	' Select first worksheet
	dim document   as object
	dim dispatcher as object
	document   = ThisComponent.CurrentController.Frame
	dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

	dim args1(0) as new com.sun.star.beans.PropertyValue
	args1(0).Name = "Nr"
	args1(0).Value =1
	dispatcher.executeDispatch(document, ".uno:JumpToTable", "", 0, args1())	
end sub
sub ToLastSheet
	' Select last worksheet
	dim document   as object
	dim dispatcher as object
	document   = ThisComponent.CurrentController.Frame
	dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

	dim iSmax as Integer
	iSmax=ThisComponent.Sheets.count
	dim args1(0) as new com.sun.star.beans.PropertyValue
	args1(0).Name = "Nr"
	args1(0).Value = iSmax
	dispatcher.executeDispatch(document, ".uno:JumpToTable", "", 0, args1())	
end sub

(In reply to geoff183 from comment #10)
> The new behavior is aligned with other common UX designs. e.g these
> applications also wrap around: xfce4-terminal, firefox, GIMP, thunar... I'm
> sure there are plenty more. I also preferred the previous way This sort of
> change probably won't be reverted or given an option.
While I've found a solution that works for me thanks to your suggestion, I feel compelled to address this observation.
The other applications you cite where navigation does wrap back around on reaching the end are all applications where the tabs don't really have an intrinsic structure/order to them.  
While users may have opened some browser tabs, or images in gimp in a specific order while working on them, in a spreadsheet the order of the tabs is often fundamental to the document's purpose, and is *always* retained when revisiting the document.
I'm not as salty as @ady was about it, but their point stands that spreadsheets are at their core about structuring particular subsets of data/content, and that is not really the case for terminals, web browsers, image editors or file managers.

UNO commands to jump to first/last are easy to implement. But without natural shortcuts such as ctrl+home/end, which are assigned to first/last content within the sheet, it's a bit pointless (but happy to submit the patch without shortcuts on request).

While I disagree with an option to prevent wraparound, an alternative might be to show the "has been wrapped" info similar to find actions in the tabbbar. Unfortunately beyond my coding skills.

(In reply to Heiko Tietze from comment #14)
> (but happy to submit the patch without shortcuts on request).
https://gerrit.libreoffice.org/c/core/+/173597 (abandoning this for now)

I agree 100% with a simple config option to prevent wraparound behaviour. The great thing is that we all use the software in different ways. My spreadsheets are always really structured, and I rely on the cycle stopping at first or last, and wrapping around is meaningless. But other people will love the new wraparound. So there's no "right way" for it to work. A software change forcing a "right way" (instead of assuming that individual users will know best) is what the likes of Microsoft and Google do, and we're surely better than that? As a former coder, I'm struggling to understand how a simple boolean config option is not reasonably straightforward to implement. Thanks to all the coders for all that you do.

(In reply to Heiko Tietze from comment #6)
> My take: introduce UNO commands for first/last sheet and keep the patch
> unconditional.

(In reply to Heiko Tietze from comment #14)
> UNO commands to jump to first/last are easy to implement. But without
> natural shortcuts such as ctrl+home/end, which are assigned to first/last
> content within the sheet, it's a bit pointless (but happy to submit the
> patch without shortcuts on request).

These two seem to cancel each other, no?
Of course, infinite flexibility is bad. But here, it seems, the new UNO commands are just overkill. Here, the expert config costs nothing; the only thing needed is checking a simple boolean in the code changed in commit 552170c9c8ad6d215aa456ba9d622af01c25d275, to decide to wrap or not to wrap. That;s it.

IMO, go with the config option, and be done.

(In reply to Mike Kaganski from comment #17)

> IMO, go with the config option, and be done.

That advance/experimental option should had been part of the original tdf#156311, instead of forcing the change of the prior behavior on every user.

If that is the way this issue will be solved, then please re-set the default behavior as it used to be (for decades), and make the alternative behavior the optional.

IOW, users that want the classic behavior should get it without having to modify advance options, whereas users that want the "cycle" behavior should be allowed to edit an advance option in order to achieve it.

(In reply to ady from comment #18)
> That advance/experimental option should had been part of the original
> tdf#156311, instead of forcing the change of the prior behavior on every
> user.

Just a noise of someone expecting others to not make mistakes. Wishful thinking, that if implemented literally, would make the project stalled. We have the idea here of making changes more freely, with the idea that it may always be fixed if proved wrong. And no, there should be no "configure for every possible change": it wasn't anticipated that this is so useful for many people, and it's not reasonable to create polls for each and every request.

So in essence: comment 18 is useless.

Another argument in favor of creating a configuration parameter to switch the behavior of Ctrl+PgUP/PgDn.

In previous versions of Calc (as in all versions of Excel), we could go to the first (last) sheet of a document using the keyboard by holding down Ctrl and pressing PgUP (PgDn).
This feature is now lost.

(In reply to Mike Kaganski from comment #19)
> (In reply to ady from comment #18)
> > That advance/experimental option should had been part of the original
> > tdf#156311, instead of forcing the change of the prior behavior on every
> > user.
> 
> Just a noise of someone expecting others to not make mistakes. Wishful
> thinking, that if implemented literally, would make the project stalled. We
> have the idea here of making changes more freely, with the idea that it may
> always be fixed if proved wrong. And no, there should be no "configure for
> every possible change": it wasn't anticipated that this is so useful for
> many people, and it's not reasonable to create polls for each and every
> request.


Talking about the specific issue (not as a general concept), the request in tdf#156311 should had been optional, not imposed to everyone. It was not _that_ hard to imagine that the change of behavior would not be welcome by many users (myself included), and the reports about it were almost immediate.

Changing some long-time behavior seems to be the norm now, as if such changes are "evident" improvements for everyone.

Additionally, the suggested option could had possibly be interpreted the other way: make the "cycle" behavior the default, and IMO the default should be the prior behavior. That point should not be "useless".

(In reply to ady from comment #21)
> Talking about the specific issue (not as a general concept), the request in
> tdf#156311 should had been optional, not imposed to everyone. It was not
> _that_ hard to imagine that the change of behavior would not be welcome by
> many users (myself included), and the reports about it were almost immediate.

Reading bug 156311 comment 2, I realize that you were one of the first to answer there. And two more comments there. And in all of them, I see no sign of a warning that this is not what you want (i.e., that there are use cases that need the old behavior). Only some terminology discussion and mention of inconsistencies in OSes.

The *creator* of an enhancement request is *never* expected to "make their requests optional". The author wants *their* problem fixed; it's not their task to think about others.

And speaking about others: of course, there *are* cases when it's easy to imagine the other use cases. And I tell you, that most people are so cool that they can predict 100% of the problems that this change would bring ... in the hindsight.

But almost always, when I raise my voice in bugs where I feel that the current behavior must be kept (maybe optionally), I see *many* people not understanding what seems obvious to me. So - no, it's NOT "not _that_ hard". What was really not _that_ hard is to realize that your tone (from start here) is not OK, and your posts imply that others have no right for a mistake.

Again: the project favors rapid changes, and relies on *users feedback* to learn, iteratively improving. It is *reasonable* to assume that any change should be unconditional, unless there is a good reason to believe otherwise. It is OK to introduce behavior change, and it will pay off, if it turns out uncontroversial; and if it turns out needing the configuration, it's something we will now know for sure, because users told that.

@Mike, I am tempted to reply to your comment 22, but instead, let's advance the ticket towards actually solving the situation.

https://gerrit.libreoffice.org/c/core/+/174745 introduces "CycleNextPrevSheetTab" boolean. It is true by default, i.e. no change of the default compared to now. The discussion what should be the default may change its default value as wanted.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5daac16a03c84f5908808be446c705e19445c150

tdf#160580: make cycling from first to last tab configurable

It will be available in 25.2.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.

*** Bug 161155 has been marked as a duplicate of this bug. ***