On some operating systems, namely Linux, switching a keyboard layout (e.g. to that of another language), the keyboard Scroll Lock indicator is turned on. This assumes its usual function is unused, and it can be cannibalized to tell us which layout is in use.
Regardless of whether that's a good or bad idea - it is the default and extremely prevalent among multi-layout Linux users.
Unfortunately, LO Calc (and perhaps other apps) interpret this as if Scroll Lock has been pressed, and changes scrolling behavior - A change that is unexpected and undesirable.
This can be addressed in several ways - either by determining such a use of Scroll Lock is in effect, or by simply making Scroll Lock never effect scrolling. The first option requires some work, while the second option is the subject of bug 112876.
I would like to see the first option implemented, but even if it's the second, the default on Linux (or on Linux with the "ledscroll(group_lock)" setting enabled) should be for Scroll Lock to be ignored.
Steps to Reproduce:
1. Open a new calc document
2. Enter some (differing) text in cells A1, A2, A3, A4
3. Scroll around with the cursor
4. Switch the keyboard layout (Scroll Lock will now have changed from on to off or vice-versa).
5. Scroll with they keyboard arrow key
Scrolling behavior differs
Scrolling behavior is identical
User Profile Reset: No
*** Bug 116250 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 112876 ***
No, Roman, this is not a dupe. What I'm describing is a bug, regardless of whether Scroll Lock for navigation is configurable or not.
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
else confirms it.
(In reply to Xisco Faulí from comment #4)
> You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
> else confirms it.
I assumed that moving it out of UNCONFIRMED (and into a DUPLICATE) also means confirmation, but ok, fair enough.
I still think it's a clear dupe of bug 112876. The "default for Linux" is too vague. Do you mean TDF build? or do you mean the distro packages?
If the former, then I would argue that Linux distros are too different, and implementing the bug 112876 would allow users to handle that as they like, thus I believe no change is required here. On the other hand, with that implementation, distro maintainers would be able to create proper defaults for those flavors where default-off makes sense.
So, unless you make this RFE dedicated only to "first option", nothing to see here.
(In reply to Mike Kaganski from comment #6)
> I still think it's a clear dupe of bug 112876.
Like I said before, even if you fixed 112876, this bug would still manifest. So it can't be a dupe. Suppose you chose to use Scroll Lock to actually lock scrolling. LO should still not confuse the keyboard layout using the Scroll Lock LED being on for Scroll Lock being pressed.
> The "default for Linux" is
> too vague. Do you mean TDF build? or do you mean the distro packages?
I qualified that phrase, but let me clarify: In many Linux distributions, when you have two keyboard layouts (particularly Hebrew, but probably some others) - the Scroll Lock LED is configured by the distribution, by default, to indicate which layout is currently being used. This is the xkb setting "ledscroll(group_lock)".
I hope this clarifies things.
(In reply to Eyal Rozenberg from comment #7)
> I hope this clarifies things.
No it does not.
I didn't ask *which distributions of Linux* are configured to treat Scroll Lock that way. I asked *which flavor of LibreOffice* are you talking about.
Linux distributions may implement the Scroll Lock involvement in the layout status differently; and taking the information would be implemented differently depending upon the software used there. There would be no single way for LibreOffice to know if that is caused by some layout-controlling software, or because of user pressed the button. It cannot be LibreOffice's duty to know it, unless there is a single (or at least a couple of) well-defined APIs for that. Today, if that's just some fancy misuse of the well-defined feature of keyboards, and the misuse is not standardized to report about itself to interested programs, you cannot just require the program to telepathically know that. If there is (i.e., a program may use some API to ask system "is Scroll Lock used by keyboard layout switcher?" in a Linux flavor/keyboard layout manager-independent way), then please point to that - that'd be fine.
In the absence of the abovementioned API, the only way for LibreOffice to not interfere with keyboard manager is using the feature from bug 112876. And here I want to repeat two my statements, hopefully emphasizing my idea:
1. LibreOffice package provided by TDF should *not* disable the feature by default, unless there is an API mentioned above, because this would hide the feature from those Linux users who don't use those keyboard layout managers. So, from TDF package's PoV, fixing the bug 112876 and providing users a way to configure it manually when needed is sufficient fix for this. No other way unless the API exists (may I repeat it again).
2. LibreOffice packages from Linux distros packet managers (which are maintained by respective teams) may decide how to configure the feature by default as they think best (e.g., from the PoV of default keyboard manager they use) - and then fixing bug 112876 is enough *for them* to do that; then for every such distro, own bug report to their respective bug tracker would be required - and again, for LibreOffice itself, the problem is closed.
So again: unless you focus on your "first option" from your comment 0, and not clutter the report with argumentative statements that don't help *fixing/implementing*, the report will become less likely to be handled and fixed.
Or, if you definitely want to make clear distinction about "providing means" and "defining (default) behavior", then this could be put this way:
1. Bug 112876 makes it possible to control the behavior statically.
2. Bug X (dedicated to implementation of your "first option") would hope to make it possible dynamically.
3. This bug 120206 asks for making the feature state from bug 112876 disabled by default for all - then IMO it's WONTFIX; or it asks to disable it for some distros using relevant managers - then it's NOTOURBUG (should be filed against those distros when Bug 112876 is fixed); or it depends upon bug X from #2 above - then it's a dupe of that bug X.
(In reply to Mike Kaganski from comment #8)
> (In reply to Eyal Rozenberg from comment #7)
> > I hope this clarifies things.
> No it does not.
> I didn't ask *which distributions of Linux* are configured to treat Scroll
> Lock that way. I asked *which flavor of LibreOffice* are you talking about.
The one that you download from libreoffice.org - the "TDF package"
> Linux distributions may implement the Scroll Lock involvement in the layout
> status differently; and taking the information would be implemented
> differently depending upon the software used there.
But right now it's not implemented at all. That is, LO considers at the LED status, not the Scroll Lock presses.
Also, it's not that distributions implement the involvement in the layout; they, at most, enable the option to use the LED indicator. The involvement in the layout is an xkb thing. Now, it's true that, theoretically, a distribution could ship a modified version of xkb or modified layout data for xkb, but I think this doesn't happen except in esoteric cases.
> There would be no single
> way for LibreOffice to know if that is caused by some layout-controlling
> software, or because of user pressed the button.
Well, yes and no. LO might not know what physically happened to trigger key press and key release event; or it might not get informed about these events at all. But this is not a problem with the distinction between the keypress and the LED status. If it doesn't know "for sure" (up to strange hacks which wire keys differently in xkb) about a Scroll Lock key press, it shouldn't assume it happened just because it notices the LED coming on.
This is hitting everyone with systems, which employ SCROLL LED for other purposes than to indicate a Scroll Lock key action.
Please trigger GUI behavior from user input such as key or button presses and not by system output such as LED lights.