Bug 40917 - UI: Calc currently scrolling only by full row height
Summary: UI: Calc currently scrolling only by full row height
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 35759 95920 98755 114849 117487 125098 149618 149869 152566 (view as bug list)
Depends on:
Blocks: Smooth-Scroll Calc-UX Calc-Cells
  Show dependency treegraph
 
Reported: 2011-09-15 12:20 UTC by Коренберг Марк
Modified: 2024-02-06 15:29 UTC (History)
27 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Коренберг Марк 2011-09-15 12:20:20 UTC
If I have spreadsheet document with large, multiline cells, I can't scroll to distance equal some part of line. full line is scrolled at once. There is no option in preferences about scrolling by line (as in Excel) and scrolling by pixels (as in Word). Please add such option, or tell me where to find it, if it exists.

The original from:
(https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/375395)
Comment 1 Rainer Bielefeld Retired 2011-09-15 22:23:18 UTC
I believe this is more or less a DUP of "Bug 34689 - UI scroll problem: Cell with dimensions exceeding screen dimensions impossible to work with".

@Коренберг Марк:
Do you agree?

Please file Bug reports with status UNCONFIRMED if your are not absolutely sure that it's not a DUPlicate, that you contributed all required background information, that the problem will be reproducible with information you can provide or that your enhancement request will be accepted! Thank you!

May be you can test <http://wiki.documentfoundation.org/BugReport_Details> for submitting bug reports?
Comment 2 Коренберг Марк 2011-09-16 03:00:37 UTC
Yes, this two bugs are connected. But they are different.

My bug specify that scrolling is always jumpy. 
Bug 34689 is in impossibility to scroll large cells.

If smooth scrolling will be implemented, both bugs will be closed.

Closing Bug 34689 may be implemented in another way.
Comment 3 Björn Michaelsen 2011-12-23 12:35:20 UTC Comment hidden (obsolete)
Comment 4 Björn Michaelsen 2011-12-23 17:01:56 UTC
needinfo keyword redundant by needinfo status.
Comment 5 Florian Reisinger 2012-08-14 14:02:19 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:03:19 UTC Comment hidden (obsolete)
Comment 7 Florian Reisinger 2012-08-14 14:07:53 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-14 14:09:59 UTC Comment hidden (obsolete)
Comment 9 Nate Graham 2017-05-04 04:41:40 UTC
Confirmed that the problem is still present with Calc 5.3.2.2. Scrolling by whole lines is jarring and unnatural. And as mentioned, implementing proper pixel-by-pixel scrolling will also resolve https://bugs.documentfoundation.org//show_bug.cgi?id=34689.
Comment 10 Nate Graham 2017-05-04 04:47:03 UTC
*** Bug 98755 has been marked as a duplicate of this bug. ***
Comment 11 tommy27 2017-05-05 08:46:37 UTC
set status to NEW since there's an independent confirmation in comment 9
Comment 12 Buovjaga 2019-05-03 11:53:01 UTC
*** Bug 125098 has been marked as a duplicate of this bug. ***
Comment 13 V Stuart Foote 2021-10-30 16:48:42 UTC
*** Bug 35759 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2021-10-30 17:42:40 UTC
From 3.5.0 builds onward, the multi-line input for the Formula Input Bar (ScInputBarGroup) provides direct editing of a an over height cell including cursor and page movements (provided by the edit engine) IMHO resolving bug 34689.

So yes, the Calc sheet rendered to VCL canvas only scrolls by single sheet rows. Note also that the provided scroll bar control (up, down, and thumb slide) also move in full row increments.

IIUC more precise/incremental scrolling has been necessary because the entire sheet is the extend of the scroll, millions of cells-thousands of columns and rows.

Contrasted to Writer tables, which provide precise/incremental scrolling (and smooth scrolling) Calc sheets are much more complex. Rendering them for more precise scrolling seems desirable but likely non-performant if the entire sheet is being manipulated. Meaning there would need to be a new view shell framework to allow off screen caching of a view port onto the sheet--controlled by the range of visible/working cells.  

Complex stuff, and requires major refactoring of Calc needing some UX envisioning. But the refactoring (to support some semblance of view ports into a sheet) may be too much for a GSOC project.
Comment 15 V Stuart Foote 2021-10-30 17:57:19 UTC
(In reply to V Stuart Foote from comment #14)
Sorry, unclear

> IIUC more precise/incremental scrolling has been necessary because the
> entire sheet is the extend of the scroll, millions of cells-thousands of
> columns and rows.
> 

rather, more precise/incremental scrolling has been impossible because the entire sheet is the extent of the scroll...
Comment 16 V Stuart Foote 2021-10-30 18:27:40 UTC
*** Bug 95920 has been marked as a duplicate of this bug. ***
Comment 17 V Stuart Foote 2021-10-30 18:27:50 UTC
*** Bug 117487 has been marked as a duplicate of this bug. ***
Comment 18 V Stuart Foote 2021-10-30 18:32:47 UTC
*** Bug 114849 has been marked as a duplicate of this bug. ***
Comment 19 Heiko Tietze 2021-11-08 12:09:55 UTC
(In reply to V Stuart Foote from comment #14)
> Complex stuff, and requires major refactoring of Calc needing some UX
> envisioning.

What exactly? The requirement is clear (and requested repeatedly in the recent survey [1]). It's expected to scroll per pixel even when the cell exceeds the window size. We have to jump to the top when going into edit mode. But besides I don't see nothing controversial.

[1] https://design.blog.documentfoundation.org/2021/10/18/results-from-the-survey-about-libreoffice-calc/
Comment 20 Michael Warner 2022-06-21 02:42:43 UTC
*** Bug 149618 has been marked as a duplicate of this bug. ***
Comment 21 V Stuart Foote 2022-07-05 17:28:24 UTC
*** Bug 149869 has been marked as a duplicate of this bug. ***
Comment 22 V Stuart Foote 2022-12-18 06:23:07 UTC
*** Bug 152566 has been marked as a duplicate of this bug. ***