[Upstream] scrolling only by full line height

Bug #375395 reported by Коренберг Марк
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
LibreOffice
Confirmed
Wishlist
OpenOffice
Unknown
Low
libreoffice (Ubuntu)
Confirmed
Undecided
Unassigned
openoffice.org (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: openoffice.org

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.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: openoffice.org-core 1:3.0.1-9ubuntu3
ProcEnviron:
 PATH=(custom, user)
 LANG=ru_RU.UTF-8
 SHELL=/bin/bash
SourcePackage: openoffice.org
Uname: Linux 2.6.28-11-generic i686

Revision history for this message
In , Lars-o-hansen (lars-o-hansen) wrote :

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!

Revision history for this message
In , Oooqa (oooqa) wrote :

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.

Revision history for this message
In , Lars-o-hansen (lars-o-hansen) wrote :

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

Revision history for this message
In , Frank-l (frank-l) wrote :

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

Revision history for this message
In , Falko-tesch (falko-tesch) wrote :

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.

Revision history for this message
In , Falko-tesch (falko-tesch) wrote :

.

Revision history for this message
In , Frank-l (frank-l) wrote :

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

Revision history for this message
In , Bluedwarf (bluedwarf) wrote :

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.

Revision history for this message
In , Frank-l (frank-l) wrote :

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

Revision history for this message
In , Kekc-reg (kekc-reg) wrote :

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

Thanks in advance!

Revision history for this message
In , Mlugli (mlugli) wrote :

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.

Revision history for this message
In , Eciffonepo (eciffonepo) wrote :

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?

Revision history for this message
In , Holt-h (holt-h) wrote :

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.

Revision history for this message
Коренберг Марк (socketpair) wrote :
Revision history for this message
Chris Cheney (ccheney) wrote :

Can you please attach an example document exhibiting this problem?

Changed in openoffice.org (Ubuntu):
status: New → Incomplete
Revision history for this message
Chris Cheney (ccheney) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in openoffice.org (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Коренберг Марк (socketpair) wrote :
  • test.ods Edit (7.4 KiB, application/vnd.oasis.opendocument.spreadsheet)
Revision history for this message
Коренберг Марк (socketpair) wrote :

I have attached document

Changed in openoffice.org (Ubuntu):
status: Invalid → New
Revision history for this message
Коренберг Марк (socketpair) wrote :

The problem exists on any document.
During the scrolling, Calc will scroll full cell at once. I need smooth scrolling (by any amount of pixels, not cells) as all other programs do.

I think, such option should be in preferences.

Revision history for this message
Коренберг Марк (socketpair) wrote :

Also, while scrolling attached document......CPU usage is 100% during 1-5 seconds....

Revision history for this message
Chris Cheney (ccheney) wrote :

The upstream bug is specifically about scrolling horizontally but it is the same issue as scrolling vertically.

Changed in openoffice.org (Ubuntu):
status: New → Triaged
Changed in openoffice:
status: Unknown → In Progress
Revision history for this message
In , Коренберг Марк (socketpair) wrote :

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)

Revision history for this message
In , Werbung-v (werbung-v) wrote :

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

Revision history for this message
In , Tonton Manu (dubreucq) wrote :

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

Revision history for this message
In , Legenda-ktu (legenda-ktu) wrote :

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.

Chris Cheney (ccheney)
tags: added: jaunty
Revision history for this message
In , Bettina-haberer (bettina-haberer) wrote :

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

Revision history for this message
In , Rabid-renaissance (rabid-renaissance) wrote :

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.

Revision history for this message
In , Raimund-szabo (raimund-szabo) wrote :

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.

Revision history for this message
In , Коренберг Марк (socketpair) wrote :

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)

Changed in openoffice.org (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Björn Michaelsen (bjoern-michaelsen) wrote : migrating packaging from OpenOffice.org to Libreoffice

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

Revision history for this message
In , Коренберг Марк (socketpair) wrote :

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)

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :

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?

Revision history for this message
In , Коренберг Марк (socketpair) wrote :

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.

Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :

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?

Revision history for this message
In , Коренберг Марк (socketpair) wrote :

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.

penalvch (penalvch)
summary: - scrolling only by full line height
+ [Upstream] scrolling only by full line height
Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

[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

Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

needinfo keyword redundant by needinfo status.

Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

[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

Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

needinfo keyword redundant by needinfo status.

Changed in df-libreoffice:
status: Confirmed → Incomplete
Revision history for this message
In , Reisi007 (reisi007) wrote :

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

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Revision history for this message
In , teelo (teelo) wrote :

Thumbs up for accepting this issue! :-)

Revision history for this message
In , Nate-b (nate-b) wrote :

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.

Revision history for this message
In , Nate-b (nate-b) wrote :

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

Revision history for this message
In , Barta-c (barta-c) wrote :

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

Revision history for this message
In , filkin (david-9ei9nyj) wrote :

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

Revision history for this message
In , aaaaa (tbreportbug) wrote :

So when will this be fixed?!

Changed in openoffice:
importance: Unknown → Low
status: In Progress → Unknown
Revision history for this message
In , Beluga (beluga) wrote :

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

Changed in df-libreoffice:
importance: Medium → Unknown
status: Incomplete → Unknown
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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

Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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.

Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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

Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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

Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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

Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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

Changed in df-libreoffice:
importance: Medium → Wishlist
Revision history for this message
In , Heiko-tietze-g (heiko-tietze-g) wrote :

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

Revision history for this message
In , Michael-warner-ut+libreoffice (michael-warner-ut+libreoffice) wrote :

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

Revision history for this message
In , Vstuart-foote (vstuart-foote) wrote :

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

Revision history for this message
In , Vsfoote (vsfoote) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.