Does scrolling with an arrow key has inertia in Calc?

English
#1

Hi, I am currently using LibreOffice 7.6.4.1 on Ubuntu 20.04 (gnome38, kernel:5.15), installed via apt.

Sometimes I navigate in Calc using the arrow keys to skip from cell to cell. It usually works fine, until I try to navigate to a faraway cell, e.g. I keep the down arrow key pushed for a second to ‘scroll’ down many rows until I get to the row that I am interested in, or something like that. If I push an arrow key for a long period and then release it, the scrolling will not stop, but continue for a long time. So if I push a key for 1 second, then the scrolling will continue for a further 1-2 seconds. If I push it more, the additional time will be longer. It seems to me that some kind of inertia is built in. I would like to be able to stop the scrolling exactly when I release the arrow key.

Also, it works fine if the page does not have to scroll. In other words, if I keep the arrow key pushed until the active cell moves to a cell that I could see at the start, then the navigation stops instantly, however, if the sheet has to be scrolled while holding down the key, that the scrolling won’t stop.

Is it a bug with LibreOffice, is it an option that I can edit, or is it a problem with my system?

P.S. Keep up the good work!

1 Like
#2

may be you should try ctrl ⇓ to jump directly to the next blockofData?

#3

Unfortunately not. Sometimes I work with sheets that have a few hundred rows, without empty rows. Using Ctrl+Arrow just skips to the end of the sheet.

I give you a more detailed example. Let’s say that I am on row number 60, and the last row that is visible in the current view is row 67. If I want to navigate to row number 70. If I keep the down arrow pressed until the active cell is at row 70, because the sheet had to be scrolled, even if I lift the key, the active cell will continuously move down (sometimes to row 75, sometimes to row 85). If I have to scroll farther, the active cell will move for an additional 10-20 seconds after I release the key. I could use my mouse, however, sometimes it is just more convenient and faster to just navigate with the arrow keys.

Maybe it is not inertia, but the system treats pressing the key as pressing it lot of times.

#11

I think this is a serious problem.
From version to version, sometimes it gets worse, sometimes better. But I can remember this since vesion 3.x.
Today I had a lot of issues with version 7.4.x on debian 12. Version 24.2.5 is better.
I tried MS Excel 2016 on windows 10 and it is just instant. no inertia nor rendering sluggishness (?) when moving with arrow keys.
I installed LO on that Windows 10 and it had no inertia, although it did not moved as fast and instantaneously than Excel. Even though the slower movement, the lack of inertia is a lot better.
I then tried Gnumeric on the Debian 12 system, and arrow moving is instantaneous, and with no inertia, using the same test spreadsheet.
so …

#12

Then you should report a bug, How to Report Bugs in LibreOffice - The Document Foundation Wiki

But as it seems to affect only Debian, maybe a bug report there?

Either way I guess PgDn covers more rows in the same amount of time and is more controllable.

1 Like
#13

It seems like this bug was already reported on the Document Foundation.
Additionally, I did some tests with different distributions (mostly in a live environment), and it seems like it is not necessarily an issue with Debian (or its derivatives), but more of a combination of hardware, kernel, desktop environment, LO version.
So it is a hit or miss if this happens to you or not, it depends on so many things. I am not sure how easily the developers could fix something like this. This means, that if you are sensitive to this bug, you should test various configurations, and maybe try a few downgraded LO versions as well from the archive (if changing the hardware/kernel/DE (usage of suggested workarounds) seems too much of an ask).

I will leave this thread open for the moment, however, since there are already several bug reports about this issue, those threads might be of use to anyone, who is waiting for a definitive fix.

#4

Scrolling updates the entire window, which takes longer than just moving the cell marker to the other cell. When the keyboard repeat kicks in, Calc can move the cell marker and receive key repeats in good order. Scrolling causes the keyboard input to lag, so multiple repeats are buffered. When you release the key, Calc still needs to read the buffered input. This “backlog” is what you perceive as inertia.

Excactly!

Solution is to jump more directly, either by block/page jumps as already suggested by @karolus, or by selecting address/named range in the Name Box address field (far left at the formula bar). Shortcut key F6 cycles through the tool/menu sections. On my system the address field can be selected by pressing 4 x F6 or 3 x Shift+F6, if you prefer not using the mouse.

1 Like
#5

Thanks for the answer, PgUp or PgDn might work (or just use the mouse). I was hoping the solution wouldn’t be a workaround. I guess it is not a critical bug, hopefully it will be corrected sometime in the future.

#6

That depends. I suspect that the lag is in keyboard buffer reading. The solution may then be to flush the input buffer on given conditions. Determining conditions for this is perhaps not as trivial as it may seem.

The lag may also be in screen updates. If so, the selection has already moved past your intended target, and I suspect that no Calc programming can fix it.

Either way, the issue comes from a fallback when your system fails to keep up with itself.

#7

Well, my laptop is indeed quite old, but I was curious so I experimented with different software. Using OnlyOffice and Google Sheets in Firefox works as expected. However, they are not as snappy as Calc (or should I say they use more resources). So I guess there is a tradeoff in the fundamental implementation (It is either snappy, but there is a lag when scrolling, or it moves slowly, but at least it has no keybuffer problems). Either way, I will continue using Calc, because it is way less resource-hungry (And just to make it clear, I am not asking the developers to rewrite the source code with a different engine, just to resolve this issue. I only wanted to know if this is a known problem, or is it just me).

#8

Ctrl+Shift+T
imagen

2 Likes
#9

Hi, recently I had a little time to dig into this a little bit.
While I appreciate the suggestions to use other methods of navigation, sometimes I just consider the arrow navigation to be more convenient.

I tried a few older releases, and I noticed, that up to and including version 7.0.6.2 the navigation works well (as soon as I release the arrow key, the scrolling stops), however at version 7.1.0.1 (the next release not considering alpha versions), this weird inertia appears. I checked the release notes, but no obvious modification appears.
I also tried version 7.6.4 on the same computer using Windows, where there is no inertia (i.e. works well).

TLDR: something was introduced/modified in version 7.1.0.1 that added inertial scrolling when using the arrow keys.
Maybe the problem is that the modification just does not play well with my laptop and Ubuntu 20.04 (I know I should upgrade). On that note, I will use version 7.0.6 as for now, and I do not necessarily expect an answer to this thread, I just wanted to have this info up for anybody else.

#10

If holding the arrow key sends 20 keystrokes per second, but the software needs 1/10 second to render the screen, the software is 50 screens behind when you release the key after 5 seconds.

Ctrl+End moves to the last cell (bottom right cell of used sheet area) in one go.

1 Like

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.