Hi, 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? Thanks (1) https://bugs.documentfoundation.org/show_bug.cgi?id=46200
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.
Hi, 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. Regards
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. Yes.
I didn't know how to point that I have this issue for 5.4.1.2 release and then I changed "Version" to 5.4.1.2, 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 > <https://bugs.freedesktop.org/show_bug.cgi?id=104050>). > > So, IMHO, no option to disable this is needed for the reasons explained > above. 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, 6.1.0.3, 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. ***
Please, make this option configurable, because as for now after so many years i can't use LibreOffice :( I have HP ZBook laptop and on Windows 10 I can not turn on ScrollLock. After research I managed to turn on ScrollLock using onscreen keyboard, and now I can move cell selection by arrow keys only up and down, but left and right arrows move a sheet itself, instead of cell selection. That's very pity and make the navigation to be very hard, I can't work in LO like this, sorry. LO 6.3.1.2 (64 bit), Windows 10 Pro, HP ZBook 15.
Hi, is it possible to make ScrollLock key to be settable as Left/Right/Up/Down keys. Can anyone explain the problem to do this?
*** Bug 140160 has been marked as a duplicate of this bug. ***
It is impossible to work when the whole sheet moves instead of moving through the cells!
I have surfed the internet a bit and it seems to me that there a number of keyboards out there that use the ScrollLock key for toggling the backlight. I have one myself now and using Calc with this is a pain. So I would like to see this fixed. Note that the above discussion is a lot about Linux, which might make this appear to be a Linux problem. But the same problem occurs on Windows if you have one of those keyboards.
The key and the implementation actually work well but, as commented before, some hardware abuses it for other purpose. So I suggest to block the scroll lock handling with an expert option (tools > options > advanced: UseScrollLock; on by default, of course). Tentative patch at https://gerrit.libreoffice.org/c/core/+/154528 Scroll lock does not work for kf5 and gtk4 but gen, gtk3 and qt6 on Linux.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4adc868328e958a4a9cead3731bd3468497c97c8 Resolves tdf#112876 - Make use of scroll lock configurable It will be available in 24.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.
Wow - a solution within nearly six years for a problem that has been implemented and did not exist before. Please forgive the snarky comment, but some "improvements" could be better thought about in advance.
(In reply to Karsten from comment #33) > Wow - a solution within nearly six years for a problem that has been > implemented and did not exist before. LibreOffice is an open source project driven by volunteers. We try our best to allow everyone to join the development whether by small improvements on the code or with design-only patches. You are welcome to contribute and will get every support.
(In reply to Heiko Tietze from comment #34) > LibreOffice is an open source project driven by volunteers. We try our best > to allow everyone to join the development whether by small improvements on > the code or with design-only patches. You are welcome to contribute and will > get every support. Heiko, it is an wonderful project and i am thankful for your work and that it exists! It would only be very nice if imagined improvements are in fact some for the users. There are many users out there who place more value on stable function than on unneeded gimmicks. That's the reason why i am still using Version 7.1.8.1, because the versions afterwards offer only more pain and bugs, then more functionality (No newer versions have been tested for a longer time now). But generally it can be said that using MS Office is causing much more pain. ;-) In the case of this bug only a little change has caused much problems for the user. It would be nice if the standard behaviour of the software would not be touched and enhancements are always optional to be used. Thank You.
(In reply to Karsten from comment #33) Lol. There are hundreds of millions (billions?) Excel users out there; and each of them enjoys ScrollLock support, working exactly the same way it was implemented almost 6 years ago in Calc. It's keyboard manufacturers (comment 30) and DE authors (~all the rest telling about strange idea to indicate keyboard layout using that indicator, as if there might only be one alternative layout/language configured on the system...) who "could be better thought about in advance". And the code pointers were there since 2018 (comment 17). If no one was affected bad enough to jump in and try to fix it, with friendly help of mentors here offering their assistance, it indicates not a huge problem...
(In reply to Karsten from comment #35) > It would be nice if the standard behaviour of the software would not be > touched and enhancements are always optional to be used. Standard behavior is not clearly defined but you are right, and we do our best. In this case scroll lock was implemented as a standard. More questionable is the second part with everything being optional. Let's better decide on every change whether it make sense to bloat the options, even when it's an advanced setting. It is bad usability if you a) have to change an option, and b) struggle to find it. > That's the reason why i am still using Version 7.1.8.1... You miss a lot of goodies :-). But the power of open source is choice, if it's the older version or a different application. We offer release candidates and nightly builds that run in parallel so you can test the new releases. Your input is very much welcome.
(In reply to Mike Kaganski from comment #36) > (In reply to Karsten from comment #33) > > Lol. There are hundreds of millions (billions?) Excel users out there; and > each of them enjoys ScrollLock support, working exactly the same way it was > implemented almost 6 years ago in Calc. And there are hundreds of other users that suffer under the non optional implementation of that feature. ;-) In the own case it was not a special keyboard, it was the behaviour of KDE that did not allow to alter the state when I remember correct. > If no one was affected bad enough to jump in and try to fix it, with friendly help of > mentors here offering their assistance, it indicates not a huge problem... Why any problem must be caused by introducing new features? Why the standard behaviour is changed and new features are not optional, so that everything keeps fine?
(In reply to Heiko Tietze from comment #37) > Standard behavior is not clearly defined but you are right, and we do our > best. Standard behaviour can be defined as the working of a software in a stable version. > In this case scroll lock was implemented as a standard. Normally your team is feeling offended when it is measured with MS Office. The nice thing of Libreoffice is to do it better. :-P > More questionable is the second part with everything being optional. Let's better > decide on every change whether it make sense to bloat the options, even when > it's an advanced setting. It is bad usability if you a) have to change an > option, and b) struggle to find it. Sorry - it is bad usability when you have to find out why the software cannot be used in a accustomed matter any more and it is really pain when you are forced to find out workarounds to compensate new "features" that will make you crazy. > > That's the reason why i am still using Version 7.1.8.1... > You miss a lot of goodies :-). The goodie is to be able to work with Libreoffice without circumnavigate the pain of workarounds. In the most cases only the absolute standard basic features are needed. An Office package is something like a basic tool for writing text or calculating in a spread sheet. Observing most other users they never use any special functionality, because they simply don't understand it. So about what kind of progress we are talking about? > We offer release > candidates and nightly builds that run in parallel so you can test the new > releases. Your input is very much welcome. Thanks - the time will come to test a new stable release. :-)
(In reply to Karsten from comment #38) > (In reply to Mike Kaganski from comment #36) > > If no one was affected bad enough to jump in and try to fix it, with friendly help of > > mentors here offering their assistance, it indicates not a huge problem... > > Why any problem must be caused by introducing new features? > Why the standard behaviour is changed and new features are not optional, so > that everything keeps fine? Often options are added, but keep in mind that this duplicates the maintenance burden of a feature. The danger is having an ever-growing fractal of test cases to care for.
(In reply to Karsten from comment #38) Please use some common sense! We are discussing the [Scroll Lock] keyboard key here, not [Kbd Layout] key. This key was *intended* specifically for the purpose of modifying the behavior of arrow keys [1]; it was intended that this key woks as it was introduced in LibreOffice 5.3. So it *definitely* was implementing *the* standard behavior. Standard for all spreadsheet software (so industry best practices compliance); standard for keyboard design; standard for the vast majority of users. The behavior before that was *not* standard (and users imagining that any behavior of their favorite version X is "standard", are just proof of https://xkcd.com/1172/). And unlimited flexibility with every feature being configurable is bad. Bad for users; bad for maintenance. If we tried to do that, we wouldn't be able to improve the program. People wanted that feature since long ago (it was introduced in 2017 to implement tdf#46200 from 2012, which had many watchers, and itself referenced i#7179 from 2002). Those people who wanted the old behavior asked for that, and finally it arrived. Those who wrote things like comment 33 after that, are just ... let me not call things their proper names. [1] https://en.wikipedia.org/wiki/Scroll_Lock
(In reply to Buovjaga from comment #40) > Often options are added, but keep in mind that this duplicates the > maintenance burden of a feature. The danger is having an ever-growing > fractal of test cases to care for. When this is a problem, then a new feature should really be needed and an advantage for the user.
(In reply to Mike Kaganski from comment #41) > We are discussing the [Scroll Lock] keyboard key here, not [Kbd Layout] key. I never discussed a keyboard layout. It was just the possibility to move the cursor in Calc with the keyboard. Of course it is not your fault that KDE has a bad interpretation of this key or that this functionality is misused by some keyboard manufacturers. But this modification was so heavy that it was impossible to work with calc after the introduction of this "feature". The different sight of a "feature" and a "bug" is normal between developers and users. :-) > And unlimited flexibility with every feature being configurable is bad. Bad > for users; bad for maintenance. That's true of course too. So let me step back that a new feature should not touch the behaviour of the version before if possible. > People wanted that feature since long ago O.K. Then you tried to do the best for the users. It was not possible to foresee the problems with special keyboards and user interfaces in advance. However, it would have been nice if there had been a quicker solution for the affected users.
It's mark as "fixed". Which version of LibreOffice has this update?
(In reply to JonIrenicus from comment #44) > It's mark as "fixed". Which version of LibreOffice has this update? See comment 32: It will be available in 24.2.0.
(In reply to Buovjaga from comment #45) > See comment 32: It will be available in 24.2.0. I saw this comment, but the current version of LibreOffice is 7.5.5. I don' understand, this option will be available in "ten years"? :) Or there are some other version numbers?
(In reply to JonIrenicus from comment #46) > (In reply to Buovjaga from comment #45) > > See comment 32: It will be available in 24.2.0. > I saw this comment, but the current version of LibreOffice is 7.5.5. > I don' understand, this option will be available in "ten years"? :) Or there > are some other version numbers? Read it as February 2024. We changed the versioning to be calendar-based.
Cherry-picked this for 7.6 coming soon.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/c7de706f5f4b32babdad1cf2ced4e79c802df46a Resolves tdf#112876 - Make use of scroll lock configurable It will be available in 7.6.0.2. 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.
Heiko, let me just say thank you for your support here. And even pulling it forward to 7.6—that is really great! This kind of support is really something that makes open-source software shine.
(In reply to Axel Niedenhoff from comment #50) > Heiko, let me just say thank you for your support here. And even pulling it > forward to 7.6—that is really great! This kind of support is really > something that makes open-source software shine. Happy to be of service. And sorry for the late patch, in the end it was pretty simple.
(In reply to Heiko Tietze from comment #51) > Happy to be of service. And sorry for the late patch, *in the end it was pretty simple*. Now you should know what I mean. ;-)
I'm happy to hear the problem has been fixed https://donkey-kong.io