Recently (1) scroll lock has started being used to navigate the document (Same as in MS Excel). However I use scroll lock to indicate current input language...
Is it possible to add an option for this?
Seems reasonable, it was also requested in bug 46200 comment 31 and in bug 111627 (which also seems to be about a bug, but needs more details from the reporter).
I'm not sure why the feature should be deactivated by default, though, that needs further reasoning. CCing the others who requested this before.
UX team, please suggest a configuration option for this.
In debian, in a multi language config it should be disabled by default as debian uses scroll lock like this by default. On other distros it shouldn't.
I would say, to keep it simple, the option shall be enabled by default (like in MS Excel) in all distributions - if needed a user could disable it somewhere in configuration - and for this we would need an option somewhere in preferences.
I also do use Debian with two keyboard layouts and don't use the scroll lock's LED to show me which keyboard layout I use. I can see it in Gnome or XFCE taskbar.
What I understand is that Shay wants to reconfigure the shortcut. For other functions that's done via tools > customize (greatly improved for 6.0) where .uno:ScrollLock should be bound to .key:ScrollLock (or whatever this is labeled internally). And this assignment can be removed or redefined.
(In reply to Heiko Tietze from comment #4)
> What I understand is that Shay wants to reconfigure the shortcut. For other
> functions that's done via tools > customize (greatly improved for 6.0) where
> .uno:ScrollLock should be bound to .key:ScrollLock (or whatever this is
> labeled internally). And this assignment can be removed or redefined.
I didn't know how to point that I have this issue for 188.8.131.52 release and then I changed "Version" to 184.108.40.206, but I forgot what was the previous version pointed, sorry. (Something like 5.3.1 or something..)
This "new feature" is really annoying. Why do I must change my system settings to appease this one program only? (I use Lubuntu 17.10 and GTK2)
LED indication of the keyboard layout is the default for Debian based distros which is a significant percentage in terms of number of users. So I don't see why LibreOffice should make its default configuration conflicting with all these systems.
Besides, as is was pointed out, it is just a third way to scroll. It is an open question how many people prefer this one.
(In reply to Sergey from comment #7)
> So I don't see why LibreOffice should make its default configuration conflicting
> with all these systems.
When a user wants to configure the scroll key him or herself, why not? By default it will be empty, of course.
Removing UX, dev please add scrollkey to customization.
(In reply to Heiko Tietze from comment #8)
> (In reply to Sergey from comment #7)
> > So I don't see why LibreOffice should make its default configuration conflicting
> > with all these systems.
> When a user wants to configure the scroll key him or herself, why not? By
> default it will be empty, of course.
> Removing UX, dev please add scrollkey to customization.
Yes, I was talking about default setting. User should be able to customize it, no question.
Scroll Lock option is needed.
(see my comment 8 at bug 111627 - https://bugs.documentfoundation.org/show_bug.cgi?id=111627#c8 for details).
This is not the disturbing of a normal feature: some people assigned a feature to the Scroll Lock key because of a bug in X11 and Wayland which prevents the key from working as expected. The normal feature, as originally intended, is to modify the behavior of arrow keys and that’s what LO Calc now does.
Also, adding an option to disable this feature means more complexity. Is the feature on or off, how will the ordinary user (possibly used to Excel which supports it) will figure it out? Not everybody reads the release notes. And what happens when or if the bug is fixed in X11 or in Wayland? (See <https://bugs.freedesktop.org/show_bug.cgi?id=94226> and <https://bugs.freedesktop.org/show_bug.cgi?id=104050>).
So, IMHO, no option to disable this is needed for the reasons explained above. If, however, developers decided to add such an option I think it should be disabled by default and the decision to enable it should be left to distro maintainers and/or the end users in order to avoid confusing the huge majority of the user base. Just my 2 cents.
Would be nice if the option gets predefined depending on the system capability whether scroll lock is available or not.
Availabilty still doesn't tell anything about whether it behaves as expected or is unexpectedly abused by some Window manager or other means as an LED indicator activating the lock.
An option scroll behaviour with 3 choices would solve the problem:
* keyboard (as read from desktop system)
* on (permanent on)
* off (permanent off)
*** Bug 116250 has been marked as a duplicate of this bug. ***
Changing the bug title because a configurable option is a possible fix, not the problem itself; and also to avoid dupes being created (like bug 116250).
Don't see why this easyhack needs much evaluation. It's known which commit ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=453de3473cf6f383c71466a1ed15e28b844ed7e5 for bug 46200 ) changed the behaviour; so the only thing that is needed is to take a new configuration into account when evaluating the value of bool bScrollLock in ScCellShell::ExecuteCursor. I am sure that Heiko could assist with the new configuration option bits.
(In reply to kolrac from comment #11)
> If, however, developers decided to add such an option I think it
> should be disabled by default and the decision to enable it should be left
> to distro maintainers and/or the end users in order to avoid confusing the
> huge majority of the user base.
(In reply to Heiko Tietze from comment #12)
> Would be nice if the option gets predefined depending on the system
> capability whether scroll lock is available or not.
I agree with kolrac on this; when an option is available, it's maintainers' task to define customized defaults when they know it makes sense on the systems they maintain (in the absence of some universal API to obtain meaningful default from system). I don't think that we should try to change the default in LibreOffice from current mode; just introduce the option to disable use of Scroll Lock state for navigation, and let maintainers/users to decide.
(In reply to kolrac from comment #11)
> Also, adding an option to disable this feature means more complexity. Is the
> feature on or off, how will the ordinary user (possibly used to Excel which
> supports it) will figure it out? Not everybody reads the release notes. And
> what happens when or if the bug is fixed in X11 or in Wayland? (See
> <https://bugs.freedesktop.org/show_bug.cgi?id=94226> and
> So, IMHO, no option to disable this is needed for the reasons explained
This feature whose only purpose seems to be to mimic Excel conflicts with both software and hardware in the real world. The comments here have mentioned some software it conflicts with. In terms of hardware, the popular Cooler Master CMStorm keyboard uses the scroll lock key to turn the backlight on and off. The keyboard is such that you need to have the backlight on, day or night, to see the key labels. This means that if you use LibreOffice you're either stuck in the bizarro scroll mode, meaning you can't use the keyboard to move around a spreadsheet, or you have to turn off the backlight, meaning you can't see the labels on your keys.
That said, using the latest LibreOffice, 220.127.116.11, in OpenSUSE Tumbleweed, and a CMStorm keyboard, the scrolling no longer occurs. I assumed LibreOffice turned it off until I found this page. If LibreOffice didn't make the change, I wonder if OpenSUSE did? Very weird.
*** Bug 120206 has been marked as a duplicate of this bug. ***
ScrollLock behavior should be configurable.
I use ScrollLock LED as indicator of alternative keyboard layout:
org.mate.peripherals-keyboard-xkb.kbd options ['grp\tgrp:ctrl_shift_toggle', 'lv3\tlv3:ralt_switch', 'compat\tmisc:typo', 'compat\tnumpad:microsoft', 'grp_led\tgrp_led:scroll']
Currently all modern version from Ubuntu (in 18.04 LTS repository and in PPA) are affected by this bug. I do not want to disable ScrollLock LED indicator.
So please add option on yours (LibreOffice) side.
This is sooo unbelivable that this stupid bug is still not fixed!
I was suffering from it so many times, and when i diceded to google it - what i saw? Proposal to change default befaviour of so many distros and DEs instead of adding a simple option?
How many users knows about Excel's behaviour with ScollLock? They are so few.. And litteraly most of non-english linux users are suffering form this "feature".
Please, make it optional. And yes. It MUST be disabled by default because now it conflicts with so many DE's. ScrollLock led as indicator is a default KDE beahavior as i understand.
If you even disable it for linux at all - almost no one will miss this terrible feature.
P.S. thx for you greate job any way :) And please, disable this stupid feature, save our nerves :)
(In reply to Vladimir from comment #22)
> ... and when i diceded to google it - what i saw? Proposal to change default
> befaviour of so many distros and DEs instead of adding a simple option?
Amazing how hard reading is.
Instead of seeing what actually is here (the proposal confirmed and set to NEW, supported by UX, and set to easy hack with code pointers, to help anyone interested to jump in and fix it), one sees such bizarre things you couldn't imagine.
Yes - this is really a bizarre thing, because before there was no problem with it.
It is just one of many functionalities that are making problems in relation to the versions of Libreoffice before.
At least it is the same like in Microsoft Office: Bugs in the current software are not fixed, but new functionalities with new bugs are added that most of the users will not miss or use.
It seems to be a general trend that software goes to be more and more complicated, only with the eye on functionality and not the usability.
*** Bug 120869 has been marked as a duplicate of this bug. ***