[Upstream] scrolling only by full line height

column A broader than current screen resolution;

when scrolling horizontically, column A jumps to column B;

data in cell in column A which was out of displayed part of cell can't be
reached visually.

Scrolling should always occur smoothly!

Lars, thanks for taking the time to post this issue.

Thank you for using and supporting OOo.

I'm going to label this as an enhancement request.

the jump is due to the current priniple of "display" of the sheet;

and I like it.

so if possible only scroll smoothly when a column is larger than the
displayable area

Hi Falko,

1 4 u

For now we can show such columns in it's entirety by changing the zoom
factor or just changing the column width by using the context menu on
the column header.

Frank

In case columns are wider than the current screen Calc should scroll
smoothly (horizontal) instead of "jumping" to the next column.
This enables the user to read-out the current (wider-than-screnn)
column's content.

.

*** Issue 39731 has been marked as a duplicate of this issue. ***

To satisfy both requests, in my opinion, smoothly scroll function should be
implemented and Calc should have UI to swtich scroll option easily, "smoothly"
or "jumping".

>For now we can show such columns in it's entirety by changing the zoom
> factor or just changing the column width by using the context menu on
> the column header.

We may not, however, see small characters zoomed out forcibly and want to change
column width all of the time when we encounter such columns.

*** Issue 43413 has been marked as a duplicate of this issue. ***

I really hope that anyone implement it in ongoing release.
I can't actually work with some documents.

Thanks in advance!

When will be implemeted the smooth scroll of the columns? There is nothing to
invent it enough copy what already does Excell.
It since 2002 this issue is opened.

This is driving me insane. I downloaded Open Office in hopes that it had a more
intelligent interface than Excel, but the same awful "feature" of scrolling a
row at a time was copied straight from Excel with no option to scroll normally.

I don't care if the row is bigger than the screen or normal sized. I lose track
of what I'm looking at when I scroll and everything jumps around erratically.
Does this really take 7 years to fix?

Issue can be bypassed by highlighting some letters or words and afterwards only
starting to drag and drop without really moving them. Then it is possible to
scroll each textrow and to normally modify and saving the text in the specific
cell/row.

I think The new option in preferences should be (combobox):
scroll by: [pixels|cells|auto]

* by pixels - scrolling as all non-table-oriented programs
* by cells - as now
* auto - scroll by pixels only for large cells (> 1/2 of window with for
horizontal scrolling, > 1/2 of window height for vertical scrolling)

why is this issue only marked as enhancement with a priority of 4?
this "bug" renders viewing and editing some spreadsheets completely impossible!
that is why this issue should be considered to be something much more serious.
especially taken into account that it has been reported 7 years ago!

the issue is reproducible on windows xp sp2/sp3 with ooo310m11 and dev300m52.

(and now i will go back to work ... on a writer spreadsheet in a writer
document with dimensions of 39x300 cm ...)

I completely agree with you pfadwaechter. Could anybody from the dev.team give
us news about the treatment of this issue?

Hello,
I'm using my netbook PC (Asus Eee 901) with screen resolution 1024x600. There is
no need to have very height rows to face this problem.
Thank you.

To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".

This is currently causing me nothing but headaches, as I'm trying to use OOo
Calc to track web app bugs and add screenshots from testing, this can make my
rows quite large and trying to resize my screenshots is pretty much impossible.
 Please provide a smooth scrolling option.

Even difficult to follow the normal documents with different column and row sizes because the jump scroll. Can you implement the smooth scroll option please? Thank you.

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)

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)

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?

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.

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?

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.

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

needinfo keyword redundant by needinfo status.

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

needinfo keyword redundant by needinfo status.

Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian

Thumbs up for accepting this issue! :-)

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.

*** Bug 98755 has been marked as a duplicate of this bug. ***

set status to NEW since there's an independent confirmation in comment 9

Accepted? - Great! - so this will be fixed in the next update?

So when will this be fixed?!

*** Bug 125098 has been marked as a duplicate of this bug. ***

*** Bug 35759 has been marked as a duplicate of this bug. ***

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.

(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...

*** Bug 95920 has been marked as a duplicate of this bug. ***

*** Bug 117487 has been marked as a duplicate of this bug. ***

*** Bug 114849 has been marked as a duplicate of this bug. ***

(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/

*** Bug 149618 has been marked as a duplicate of this bug. ***

*** Bug 149869 has been marked as a duplicate of this bug. ***

*** Bug 152566 has been marked as a duplicate of this bug. ***